More precisely, unless otherwise specified, a unix shell is compatible with the POSIX / Single UNIX shell specification. Most unices have a such a shell available as
- command-line for when you want to do something without a GUI, and your question isn't particularly about the command interpreter
- terminal for questions about the surrounding text mode environment
Main Bourne-style shells
- bourne-shell The Bourne shell is one of the two surviving shells from the old days, now mostly superseded by various shells called ash, ksh and bash. The POSIX specification builds on the Bourne shell.
- bash Bash is a Bourne-style, POSIX-compliant shell from the GNU project. It is the default interactive and scripting shell on most Linux distributions, and available on most other unices. Bash adds many features, both for scripting and for interactive use.
- ksh Ksh is a Bourne-style, POSIX-compliant shell. It adds many advanced features, mostly for scripting. Although ksh has been open-source since 2000, it is still less favored in the open source world, and there are several partial ksh clones.
- zsh Zsh is mostly Bourne-style, but with a few syntactic differences. It has a POSIX emulation mode. It has many extra features, both for scripting and for interactive use.
- busybox Busybox is a contains a mostly POSIX-compliant shell with some line edition capabilities together with many simple utilities. It is targetted towards embedded systems.
Other well-known shells
- csh tcsh The C shell is one of the two surviving shells from the old days. It is not favored for scripting. The main implementation today is tcsh. C shells used to have more interactive features than Bourne-style shells, but bash and zsh have now overtaken tcsh.
- fish Fish is a relative newcomer inspired by classical and aiming to combine power and simplicity.
- What are the fundamental differences between the mainstream *NIX shells?
- Object-oriented shell for *nix
These are features commonly found in shells with good interaction support (bash, tcsh, zsh, fish):
- line-edition command line edition, often with configurable key bindings. readline in bash.
- command-history a history of commands that can be navigated with the
Downkeys, searched, etc.; also a recall mechanism based on expanding sequences beginning with
- autocomplete completion of partially-entered file names, command names, options and other arguments.
- job-control management of background processes.
- prompt showing a prompt before each command, which many users like to configure.
- alias defining short names for often-used commands
- What is the exact difference between a 'terminal', a 'shell', a 'tty' and a 'console'?
- What are your favorite command line features or tricks?
- What features are in zsh and missing from bash, or vice versa?
- Colorizing your terminal and shell environment?
- best way to search my shell's history; How to access the history on the fly in unix?
Shells have traditional control structures (conditionals, loops) as well as means to combine processes (in particular the pipe). They have built-in support for a few tasks such as arithmetic and basic string manipulation, but rely on external commands for other things.
Almost every unix-like system provides a POSIX-compliant shell, usually as
/bin/sh. So scripts aiming to be portable between unix variants should be written according to that standard, and start with the
#!/bin/sh shebang line.
Many systems have at least ksh or bash available. These provide a number of useful extensions, though not always with the same syntax. Features present in both (and in zsh) include local variables in function, array variables, the double bracket syntax for conditionals (
[[ … ]]), and (requiring an option to be set in bash and zsh) additional globbing patterns such as
A common difficulty in shell programming is quoting. Unlike in most programming languages, almost everything is a string, and quoting is only necessary around special characters. However some cases are tricky. In particular, a common pitfall is that variable and common substitions (
$(foo)) undergo further expansion and should be protected by double quotes (
"$(foo)") unless that further expansion is desired.
- quoting a tricky aspect of shell programming
- wildcards globbing, i.e., using patterns to match multiple files
- io-redirection connecting the input or output of a command to a file
- pipe connecting the output of a command to the input of another command
- file-management text-processing two common shell tasks
- utilities Shells often call external utilities dedicated to one particular task.