Shell Programming 159 endif produces this error: foo: Undefined variable. To get the script to “do the right thing,” you have to resort to a script that looks like this: #!/bin/csh unset foo if ( ! $?foo ) then echo foo was unset set foo else if ( "$foo" = "You lose" ) then echo $foo endif [Notice the need to ‘set foo’ after we discovered that it was unset.] Clear, eh? Error Codes and Error Checking Our programming example glossed over how the file command reports an error back to the shell script. Well, it doesn’t. Errors are ignored. This behavior is no oversight: most Unix shell scripts (and other programs as well) ignore error codes that might be generated by a program that they call. This behavior is acceptable because no standard convention exists to specify which codes should be returned by programs to indicate errors. Perhaps error codes are universally ignored because they aren’t displayed when a user is typing commands at a shell prompt. Error codes and error checking are so absent from the Unix Canon that many programs don’t even bother to report them in the first place. Date: Tue, 6 Oct 92 08:44:17 PDT From: Bjorn Freeman-Benson bnfb@ursamajor.uvic.ca Subject: It’s always good news in Unix land To: UNIX-HATERS Consider this tar program. Like all Unix “tools” (and I use the word loosely) it works in strange and unique ways. For example, tar is a program with lots of positive energy and thus is convinced that noth- ing bad will ever happen and thus it never returns an error status. In

160 csh, pipes, and find fact, even if it prints an error message to the screen, it still reports “good news,” i.e., status 0. Try this in a shell script: tar cf temp.tar no.such.file if( $status == 0 ) echo "Good news! No error." and you get this: tar: no.such.file: No such file or directory Good news! No error. I know—I shouldn’t have expected anything consistent, useful, doc- umented, speedy, or even functional… Bjorn Pipes My judgment of Unix is my own. About six years ago (when I first got my workstation), I spent lots of time learning Unix. I got to be fairly good. Fortunately, most of that garbage has now faded from mem- ory. However, since joining this discussion, a lot of Unix supporters have sent me examples of stuff to “prove” how powerful Unix is. These examples have certainly been enough to refresh my memory: they all do something trivial or useless, and they all do so in a very arcane manner. One person who posted to the net said he had an “epiphany” from a shell script (which used four commands and a script that looked like line noise) which renamed all his '.pas' files so that they ended with “.p” instead. I reserve my religious ecstasy for something more than renaming files. And, indeed, that is my memory of Unix tools—you spend all your time learning to do complex and peculiar things that are, in the end, not really all that impressive. I decided I’d rather learn to get some real work done. —Jim Giles Los Alamos National Laboratory Unix lovers believe in the purity, virtue, and beauty of pipes. They extol pipes as the mechanism that, more than any other feature, makes Unix Unix. “Pipes,” Unix lovers intone over and over again, “allow complex