- Huge immediately available “library” of external commands, providing lots of out-of-the-box functionality. You don’t even need to “import” or “require” to get it.
- Easy manipulation of files and processes with good syntax for these tasks
- Pipes make combining programs very easy
- Always installed (OS X comes with version 3 for some reason, version 4 is easily installable).
The pros above make bash the best language for many system tasks (and not Ruby, Perl or Python for example).
- Horrible syntax for general purpose programming tasks (read anything that is not a process or file manipulation), probably consequence of bash not being designed as a programming language. Language features were added with time in a backwards compatible way. The syntax looks really bad.
- No nested data structures
- No exceptions
- No named function parameters
- Subshells are forks, preventing global variables changes to be visible outside of the subshell. Combined with very “interesting” rules of what is a subshell and what is not, this behaviour can be surprising.
- Default behaviour is not to exit if one of the commands returns an error (use
set -eto change)
- Default behaviour is to treat unset variables as empty strings (use
set -uto change)
- Behaviour switches with
set– Action at a distance anti-pattern
- Default prompt does not include critical information: exit code of the last command
- No semantic understanding of the output and hence no command line completion based on output of previous commands. What makes me angry the most, completing
apt-get install HEREwill use the whole available packages list, not the output of the
apt-cache search ...you just used to find your package while most of the time completing based on the output would be the right thing.
- History includes the commands and sometimes timestamps but no relevant context such as working directory, relevant variables’ values, exit code, etc…
- Inconvenient programming
What’s being done about the numerous cons?
I don’t see much being done about these in bash. Backwards compatibility and the fear of potentially breaking huge amount of existing code is probably the reason.
There are alternative shells being/were developed. Unfortunately for compatibility and other reasons they don’t seem to address all of the cons. Some of this projects ruin the simple syntax for process and file manipulation by basing themselves on an existing general purpose programming language.
NGS, a new and completely different shell, does aim to fix all the cons while keeping the positive aspects of shell programming.
The bigger part of the language is already implemented. See how it looks like.
You are welcome to join the project.