>Why BASH instead of another programming language?
>Is the default shell for all OSs except for Windows
BSD users would very much disagree, as would embedded Linux users and others. In fact, this assumption is a very common cause of portability problems for free and open source software.
I'm as guilty as anyone of assuming every shell is bash but when I had to make my software compile and run tests on both Linux and FreeBSD straight out of the repository I discovered that targeting the POSIX shell was not as limiting as you might think. I have since made it a habit to avoid "bashisms" in most scripts; a good way to start with that is to learn what is and isn't a bashism using a handy list found at http://mywiki.wooledge.org/Bashism.
Agreed. Many/most of the shell scripts I've ever seen using 'bash' could be using the standard 'sh' instead; most need no changes at all, and the rest need just a few minor tweaks to eliminate non-POSIX-compliant behavior.
Since Debian and other distros now use the BSD-licensed `dash` as their default system shell (system, not user) I suspect they've become more motivated to reduce unnecessary bashisms in shell scripts. Debian's 'devscripts' project includes a Perl script called 'checkbashisms' which you can use to detect many of these common 'bashisms'.
For those of you running Ubuntu, you can install 'devscripts' with apt-get: sudo apt-get install devscripts
For those of you running FreeBSD, you can install 'devscripts' from the devel/devscripts port.
Give checkbashisms a look. You can install it on Debian and its derivatives with
sudo apt-get install devscripts
Edit: It's a bit hard to find a current checkbashisms version on the Web (the one on SourceForge is an abandoned fork of an older version), so I've uploaded a recent stable one to http://pastebin.com/Ncu6DRuM. If you're not on Debian and decide to keep it clone git://anonscm.debian.org/collab-maint/devscripts.git.
Bash is much more powerful than it's usually thought of (I wrote a decent chunk of bash code, there are middle-sized projects like DKMS written in bash, etc), but still it's a language for a narrow niche (file-management and gluing other tools) with a lot of limitations:
- very weak data structures support: no trees, no decent maps (`declare -A` seems to be searched in linear time), no arrays-in-arrays;
- no typing at all, everything is a string;
- it does not have a complete standard, very much behavior is implementation-specific;
- heavy dependence on external tools (they're like libraries in modern languages);
- stunning amount of pitfalls in syntax and corner cases, escaping hell (e.g.: `scp host:"File\\ name\\ with\\ spaces" .`).
Although I have to say that multiple jobs orchestration is amazing for a language from 70ths.
Bash/sh/zsh family is brilliant at intense interaction with humans. Aliases, short built-in commands, oneliner-oriented nature, keyboard ergonomics, really concise file/process handling - all of this makes it _the shell_.
I think it's hard for a language to be both suited for interactive and scripting programming, Python/Ruby/Node explicitly are languages for "heavy" scripting, they're poor choices for spending all day long with in a shell. Conciseness and obscurity of bash makes it a poor choice for "heavy" scripting. Also I think that Perl would be a nice shell and maybe that's why it's so often blamed for write-only code.
One attempt which comes close, I think, is Shelly. It's in Haskell and it's definitely not quite right for interactive(!) human interaction, but I'd use it for any remotely non-trivial scripts where quoting might be an issue.
Nearly everything in the slides can be done in portable POSIX sh(1) with only minor syntactic changes to avoid bashisms.
If you really want a big shell with more language features, check out ol' AT&T ksh¹, with things like nestable structured types and floating point arithmetic. [EDIT: and 'call by reference' using variable names, to address the problem of returning or mutating complicated things.] Some of bash's features originated in ksh, as did most of the POSIX sh features added since original sh.
1. Bash is definitely not the default OS shell for "all OSs" except Windows. Most Android devices, most embedded devices running a variation of Linux, a lot of Unix systems and increasingly more desktop Linux systems don't run bash as a default.
2. Pretty much every shell invokes a myriad of native binaries. That's kind of what a shell does. cmd.exe does that just as easy as bash does.
Don't get me wrong, bash is nice, but the opening part of this presentation is bullshit. Also, what the fuck happened to O'Reilly?
You can still use the Google viewer functionality without having to log in (i.e. "anonymously"), if you toss the original URL into the right Google URL. I don't have that particular Google URL (prefix) noted on this machine.
P.S. Here's another way to get at it, and what look to be links to pages with further details.
Bash has many features and for me has been useful to know because it's almost everywhere, but it was never designed to be what it has become. I'm working on escaping it forever with gherkin, a Lisp I wrote in Bash 4.
My experience with bash: Once you do something a bit more complex where bashisms would be handy any shell is so slow and complicated to use that you're better of with Python, even if all your system provides is Python 2.4. And Python is pre-installed under every (non-embedded) Linux distribution I've seen and also on Mac OS X.
Python is more powerful than shells but at the same time has a much simpler syntax (much less to remember). The only thing I miss in Python sometimes is how easy you can do complex piping in shells. It's possible in Python but not at all as handy as in (ba)sh.
The syntax you quoted is doing a logical AND of two expressions. Expressions are any bit of script - including calls to executables (like the example).
It's a pity that PowerShell is Windows-only (Pash notwithstanding); its syntax is small, supports pithiness and verbosity equally well, and has an easy to understand flow once you're over the first learning hump.
I know you jest, but the reason why shell programming uses 0 for success is understandable: that way you can have distinct non-zero returns for different kinds of errors (and several Unix utilities do have them). Arguably, testing for non-zero is a more satisfying idiom than testing for "non-one".
The shell is closely tied to running commands and the exit code of commands make up the true/false values. "return 0" in the main function of a C program means "no error" which is interpreted as true by the shell. Different non-zero return values signal different command (program) specific error states.