Grabbing Status In A Script

Posted Thursday, 11 January 2007, 11:48 am

Continuing my earlier theme of Things Unixly, here’s another mildly novel technique that I don’t think many folks are too familiar with.

I’ve written a lot of shell scripts over the years. Back in 1999, I needed to write a script to back up my servers to a DLT jukebox. Sure—there’s commercial apps out there that’ll take care of all the nitty-gritty, but I’m the kind of guy who prefers to get the nitty-gritty under my nails. So I did it myself.

The details of the script are really immaterial. I had a small program that could issue control commands to the jukebox, and the script would step through each of the servers I needed to back up, and step through the DLT tapes along with it.

One of the first problems I ran across was, ‘how can I tell whether the backup was successful’—which went hand in hand with ‘if the backup wasn’t successful, I still need to have the jukebox move to the next tape’. But beyond that, I needed to know whether the tape actually—really and truly—had been moved into the slot it was supposed to move into after a backup was complete. If the control software had failed to move a just-written-to tape out of the recorder, I definitely did not want it to just continue merrily on its way, overwriting the backup it just made!

So how do you check the status of a command that’s been issued within a shell script? With the little-known


Looks kind of silly, all alone on a line like that, doesn’t it? It’ll make more sense if I reproduce a small chunk of the script:

movejb.bin /dev/jb0 240 ${TAPE} > /dev/null 2>&1
  if [ ${STAT} -ne 0 ] ;then
   echo "${ABORT}\
   \n\nUnload tape ${TAPE} failed exitcode ${STAT}"\
   | mail -t ${PAGER}
   exit 1

‘movejb.bin’ is the jukebox controller program. Redirecting standard out and standard error is, uh, a standard practice so that your script doesn’t spill out text on the console while it’s running. But what we care about is the line immediately after that—


That line ‘grabs’ the status output of the command that just ran, and sets it within the variable ‘STAT’. We can then test the variable to see what that output code actually was. This works for almost any Unix command you throw at it. You can do the same with grep, to test whether it did or did not find the string you were looking for in its output.

The rest of the script should be reasonably self-explanatory to any Unix jock. In this portion of the script, if the status indicated that the tape had not been moved out of the recorder and back into its space in the jukebox, we knew a pretty critical error had occurred—the jukebox possibly locked up—so it was best to completely exit the backup script, and alert the poor sap on pager duty, usually me!

Beware though, there is no genuine standard for exit codes. As well, not all manpages even list what the expected exit codes might be after the command is run. Always check the manpage, but if you can’t, write a standalone snippet and test the output yourself—easily enough done for example with

echo $STAT

Make sense? I hope so. If not, please let me know—it’s easy for me to gloss over critical parts of things like this, since it’s all practically hardwired in my brain.


Unix Tech Digits Puters


Made with WordPress and the Semiologic CMS | Design by Antonella Pavese