on the edge

computers & technology, books & writing, civilisation & society, cars & stuff


Greg Black

gjb at gbch dot net
Home page
Blog front page


If you’re not living life on the edge, you’re taking up too much space.


FQE30 at speed



Syndication / Categories

  All
   Announce
   Arts
   Books
   Cars
   Family
   House
   Meta
   People
   Places
   Random
   Society
   Software
   Technology
   Writing



Worthy organisations

Amnesty International Australia — global defenders of human rights

global defenders of human rights


Médecins Sans Frontières — help us save lives around the world

Médecins Sans Frontières - help us save lives around the world


Electronic Frontiers Australia — protecting and promoting on-line civil liberties in Australia

Electronic Frontiers Australia



Blogroll

(Coming soon…)



Software resources


GNU Emacs


blosxom


The FreeBSD Project

Fri, 04 Nov 2005

Shell horrors

I 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:

  • Is this a quick and dirty script that will be run manually and where errors will be apparent to the user and easy for her to fix?
  • Is it something that gets run in the dead of night by cron that everybody expects to work perfectly (and relies upon)?
  • Does it have multiple paths to failure, or is it something that will always work as planned? (And can we be sure of that?)
  • Will it cause us grief if it doesn’t contain recovery code to handle an unexpected full disk or other similar show-stopper?

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.)