Shells in Linux

A shell is a command-line interpreter or shell that provides a traditional user interface for the UNIX operating system and for Unix-like systems. Users direct the operation of the computer by entering commands as text for a command line interpreter to execute or by creating text scripts of one or more such commands. The versatility of the command-line shell is what really allows this, but what makes each shell different and why do people prefer one over another?

 Fig1: Shells in Linux

The most influential UNIX shells have been the Bourne shell and the C shell. The Bourne shell, sh, was written by Stephen Bourne at AT&T as the original UNIX command line interpreter; it introduced the basic features common to all the UNIX shells, including piping, here documents, command substitution, variables, control structures for condition-testing and looping and filename wildcarding. The language, including the use of a reversed keyword to mark the end of a block, was influenced by ALGOL 68. The C shell, csh, was written by Bill Joy while a graduate student at University of California, Berkeley. The language, including the control structures and the expression grammar, was modeled on C. The C shell also introduced a large number of features for interactive work, including the history and editing mechanisms, aliases, directory stacks, tilde notation, cdpath, job control and path hashing.

Users typically interact with a modern UNIX shell using a terminal emulator. Common terminals include xterm and GNOME Terminal. Both shells have been used as coding base and model for many derivative and work-alike shells with extended feature sets.

What Do Shells Do?

The command-line is a very interesting thing. Once considered to be the most advanced user interface, it has gone the way of waistcoats and fountain pens: shunned to the periphery. While you still see much of the purpose and utility in them, they’re usually left aside primarily for enthusiasts to appreciate, mainly because they spend the time to learn the ins and outs of them. Indeed, the command-line in any given operating system will have a lot of quirks because easy OS interprets commands differently. Today, this is mainly an issue between Linux, OS X, and Windows, but before this was a problem with most computers.

 Fig2: Shell types

Shells entered the picture and allowed a more standard extension of the command-line in a way that was much more inconspicuous. Shells added a lot of functionality, such as command and file name completion and more advanced scripting abilities, and helped bring some performance enhancements. They also did a lot to cover some annoying problems. For example, in Unix, you couldn’t back up through symlinks to the directories before you followed them. All in all, they added some features that allowed users to get their jobs done more quickly and efficiently, just like Linux’s plethora of alternative Window Managers.

Why Are There So Many?

The most prominent progenitor of modern shells is the Bourne shell – known as ‘sh’ – which was named after its creator Stephen Bourne who worked at AT&T. It became the default UNIX command-interpreter because of its support for command substitution, piping, variables, condition-testing, and looping, along with other features. This was in an era that programming really went along with using the command-line, a practice that many argue has been diluted today. It did not offer users much leeway in customizations for users, such as aliases, command completion and shell functions.

Fig3: Shell varieties

C shell (‘csh’) was developed Bill Joy at UCB and really shook things up. It added a lot of interactive elements that users could use to control their systems, like aliases (shortcuts for long commands), job management abilities, command history, and more. It was modeled off of the C programming language, an interesting idea because UNIX was written in C. It also meant that users of the Bourne shell had to learn C so they could enter commands in it. In addition, it had tons of bugs which had to be hammered out by users and creators alike over a large period of time. People ended up using the Bourne shell for scripts because it handled non-interactive commands better, but stuck with the C shell for normal use.

Over time, lots of people fixed the bugs in and added features to the C shell, culminating in something called ‘tcsh’. The problem, then, was that in distributed Unix-based computers, csh was still the default, and had some added “non-standard” features added in, creating a very fragmented mess of things (in retrospect). Then, David Korn from AT&T worked on the Korn shell – ‘ksh’ – which tried to mitigate the situation by using the Bourne shell’s language as a basis, but added in all of the new features that everyone was accustomed to. Unfortunately for many, it wasn’t free.

 Fig4: tcsh

Another response to the hectic proprietary csh implementations was the Portable Operating System Interface for UNIX, or POSIX. It was a successful attempt at creating a standard for command interpretation and eventually mirrored a lot of the features that the Korn shell had. Simultaneously, the GNU project was going on and was an attempt at creating a free operating system that was completely Unix-compatible. It developed a shell for its own purpose: the Bourne Again shell, formed by bashing together features from sh, csh, and ksh. The result, as seen in retrospect, was pretty impressive.

Kenneth Almquist created a Bourne shell clone – ‘ash’ – that was POSIX-compatible and would become the default shell in BSD, a different branch/clone of UNIX. Its uniqueness is that it’s really lightweight, so it became extremely popular in embedded-Linux systems. If you have a rooted Android phone that has Busy Box installed, it’s using code from ash. Debian developed a clone based on ash called ‘dash’.

 

Fig5: Ash

One of the most prominent of “new” shells is ‘zsh’, developed by Paul Falstad in 1990. It’s a Bourne-style shell that takes features from bash and previous shells and adds even more features. It has spell-checking, the ability to watch for logins/logouts, some built-in programming features like bytecode, support for scientific notation in syntax, allows for floating-point arithmetic, and then some. Another is the Friendly Interactive Shell, ‘fish’, which focuses on command syntax that’s easy to remember and use.

On the whole, most shells were created as clones of previous shells that added functionality, fixed bugs, and bypassed licensing issues and fees. The notable exceptions are the original Bourne shell and the C shell, and both rc shell and ash which aren’t entirely original but definitely have some niche-utility.

Which Should I Use?

With so many out and about, you’d think that it’s hard to choose which shell to use, but it’s actually not very difficult. Since so many are based off of Bourne shell, basic things will be the same between most shells.

 Fig6: Shell choices

Bash is the most widely used shell out there and is the default for most Linux distributions. It’s really robust and has tons of features, most of which you probably won’t use unless you program, so it’s pretty safe to say you can stick to this one. Because it’s so common, it’s perfect for scripting things that will be used across different platforms. If you want to try something different that’s a little more user-friendly, you can try out fish instead.

If you tinker with embedded-Linux systems a lot, like to put Linux on ridiculous things like your Nintendo DS, or you really like Debian, then ash/dash is probably best suited for you. Again, it works mostly like the others, but since it’s sort of bare-bones and light-weight, you’ll find some more complicated functionality missing.

Fig7: Zsh

If you plan on programming or learning to develop on the command-line, then you’ll have to be a little choosier. Bash is a fine choice, but I know enough people who have switched to Zsh for its extras. I guess it really depends on how complicated your projects will get and what type of functionality you prefer from your shell. Some people still stick to tcsh because they know and use C regularly and it’s easier for them. Odds are that if you’re not sure which shell to choose, you probably don’t program much, so try to choose something that will line up with what you want to learn and do some research on what others in that field use.

You can easily install and remove different shells using the Software Center on Ubuntu or your preferred package manager. Shells are located in the /bin/ directory, and as long as you’re running a modern Linux distribution, it’s easy to change what your default is. Just enter the following command:

• chsh

You’ll be prompted for your password, and then you can change to a different shell by entering its path.

 

Fig8: Chsh 

In square brackets, you’ll see your current default, and if you want to leave it as-is, just hit Enter.

So guys, which shells you use or prefer? Do comment.