I can't read the article now, but in my opinion the fact that it's so difficult to write robust shell scripts above a very basic level of complexity (e.g. do this, then do that, then do that, then quit) really means you should be scripting in perl/python/ruby/etc instead.<p>Yes, the overhead for anything quick and dirty is higher, but if you're writing libraries, you only have to write them once.<p>The only real benefit to writing something complex entirely in a shell script is if you can't control the environment it will run in, and you need it to run everywhere, and you can't make users install an interpreter, which are increasingly rare requirements, and even then you have to write it in `sh` anyway.
These are generally good tips. I swear by<p><pre><code> set -e # same as set -o errexit
</code></pre>
and I like using list constructs (&& ||) in lieu of simple `if` test blocks but it's really important to remember that list constructs aren't exactly the same. This always catches me out:<p><pre><code> if [ -e "missingfile" ]
then
echo "you'll never see this"
fi
</code></pre>
(above runs fine with set -e)<p><pre><code> [ -e "missingfile" ] && echo "you'll never see this"
</code></pre>
(while that one correctly fails and thus `set -e` fails the script)<p>I generally stick an `|| true` on the end of those list constructs.<p>fwiw.
Text only cache, courtesy Google -
<a href="http://webcache.googleusercontent.com/search?q=cache:-aFhMx4TME8J:www.davidpashley.com/articles/writing-robust-shell-scripts.html&hl=en&strip=1" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:-aFhMx4...</a>
He suggests using<p><pre><code> if [ "$filename" = "foo" ];
</code></pre>
Why not<p><pre><code> if [[ $filename == "foo" ]];
</code></pre>
?<p>EDIT: aware of the fact that [[ ]] is a bash extension, but the actual title of the post is "Writing Robust Bash Shell Scripts", implying that it should be using the best stuff for BASH.
<p><pre><code> set -u
</code></pre>
Another great thing I could have read in the effin manual.<p>He could have added a little reminder about the ${VAR:-default} syntax. [[ <a href="http://www.ooblick.com/text/sh/" rel="nofollow">http://www.ooblick.com/text/sh/</a> search for Quasi-variable constructs ]]<p>Great read, thanks.
It's strange how the quoting trick seems to work, even when double quotes appear in in a variable. For example:<p><pre><code> Ives ~ $ FN='"a b"'
Ives ~ $ if [ "$FN" = '"a b"' ]; then echo "Does not matter"; fi
Does not matter
</code></pre>
Still works fine, so clearly something more than simple variable expansion is going on here. It seems like the end-of-literal-string matching is performed before variable expansion.
The premise is flawed. Robustness requires a shell that works the same across platforms and across time, and that means /bin/sh.<p>Most of the people reading this article, IME, are not familiar with /bin/sh, or its differences from /{bin,usr/bin,usr/local/bin}/bash, much less know how or why it is important to write robust AND portable shell scripts.
Why did you change the title of the post? The actual title according to the HTML is "Writing Robust Bash Shell Scripts" and your title is "Writing robust shell scripts"/