Shell scripting is a rather useful skill, but the language tends to be picked up ad-hoc, by putting normal shell usage in a script, cribbing bits of existing scripts, or pulling odds and ends off the internet. You can learn a fair amount from man pages and some online guides, but getting a handle on best practices, and what actually makes a portable shell script, is a bit more difficult.
So, it's nice to read a book that introduces shell scripting properly, allowing me to treat it that little bit more formally. As I've blogged before, shell scripting seems to be particularly good at going wrong with files with spaces and other funny characters in their names. I was hoping this book would help with that, but the answer really seems to be that shell's not terribly suitable for that.
What the book is good for is introducing quite a wide Unix shell scripting toolkit. I'm embarassed to say that I was previously unaware of "comm" and "join", let alone the funny corner cases and extra flags of all the tools. I now very much appreciate "awk", which I'd never really looked at before. While shell is good at kicking off processes, "awk" does make a lot of ad hoc text munging a lot easier. "sed" provides some basic operations, but "awk" is pleasantly powerful, and is just dead useful as a more convenient "cut" if the separators are tricky.
Having read the book once, I'm going to have to keep it nearby as I work. I'm now aware of so much more stuff, but it's not going to stick in my head until I've used it a few times.
Generally, though, it's made me think about the shell scripting approach. I'm naturally a "strictly type it" kind of person, and the idea that data as free-form text streams work best is somewhat odd. The fact it's so effective and so pervasive now, against my intuition of how things should work, is most interesting.
The other thing it makes me think about is language design. Shell is an ugly language. Looking at shell and awk, I can see where perl is coming from, with an expressive, tricksy, powerful but unmaintainable language. Shell and awk are a bit irregular, powerful in their domain, and constrained. In perl, constraints are removed, but the high-level ideas aren't separated from the ad hoc syntax and mysterious special cases, and it all falls apart a bit.
Even within shell, by the time the book gets to the bash extensions, the original messy but simple Bourne shell ideas become a convoluted maze of extensions and additions. A few decades have taught us how to create high-level, expressive languages without losing maintainability, and the real trick is to avoid being tempted to write things in shell and awk that you shouldn't!
Anyway, back to the book. It's good, even if it attempts to tempt you into writing things in shell that should really be done in a more modern scripting language.
Posted 2014-12-09.