on the edge
computers & technology, books & writing, civilisation & society, cars & stuff
Greg Blackgjb at gbch dot net If you’re not living life on the edge, you’re taking up too much space.
Syndication / Categories
All Worthy organisationsAmnesty International Australia — global defenders of human rights Médecins Sans Frontières — help us save lives around the world Electronic Frontiers Australia — protecting and promoting on-line civil liberties in Australia Blogs(Coming soon ) Archives(Coming soon ) Software resources |
Fri, 04 Nov 2005Shell horrorsI borrowed my title from Sarah’s story, but I’m not sure I share the angst. Of course, since we don’t get to see the “22 lines of code including if’s and for’s”, it’s impossible to know if there is reason for concern beyond the obvious—what happens to the output file if we bail in the middle because of a bug or unexpected data? As a general matter, wrapping up relatively lengthy script sections inside a loop or a sub-shell and collecting all the output into a single redirection or pipe is common shell programming practice. Whether it’s advisable depends on many factors:
There are more questions, but that list gives the flavour of the ones that would need to be addressed. My own shell horror from yesterday was a script to start a binary that built a loop with: while /bin/true ; do # stuff done What’s so bad about that? It’s bad because the installer didn’t bother to discover if there was a /bin/true, but just blindly assumed it. (I will say that the decision by the FreeBSD folk to move true to /usr/bin—which happened many years ago—seems to me to have been an error, but it happened.) And it’s bad because the “standard” idiom is so much better for several reasons: while : ; do # stuff done This is faster and neater and it will always work—certainly on any sh that came out in the last 20 years (and that’s got to be good enough). (I’ve run out of time to research just when “:” first appeared, but it’s in at least one 1987 reference next to my desk.)
|