182 Programming but Joey doesn’t know that. Or maybe he is using quotes but is using a compiler with slightly different search rules for include files. The point is that Joey is hosed, and it’s probably not his fault. Having a large number of header files is a big pain. Unfortunately, this sit- uation occurs whenever you try to write a C program that does anything useful. Header files typically define data structures and many header files depend on data structures defined in other header files. You, as the pro- grammer, get the wonderful job of sorting out these dependencies and including the header files in the right order. Of course, the compiler will help you. If you get the order wrong, the com- piler will testily inform you that you have a syntax error. The compiler is a busy and important program and doesn’t have time to figure out the differ- ence between a missing data structure definition and a plain old mistyped word. In fact, if you make even a small omission, like a single semicolon, a C compiler tends to get so confused and annoyed that it bursts into tears and complains that it just can’t compile the rest of the file since the one missing semicolon has thrown it off so much. The poor compiler just can’t concentrate on the rest. In the compiler community, this phenomenon is known as “cascade errors,” which is compiler jargon for “I’ve fallen and I can’t get up.” The missing semicolon has thrown the compiler’s parser out of sync with respect to the program text. The compiler probably has such a hard time with syntax error because it’s based on yacc, which is a great tool for pro- ducing parsers for syntactically correct programs (the infrequent case), but a horrible tool for producing robust, error-detecting and -correcting pars- ers. Experienced C programmers know to ignore all but the first parse error from a compiler. Utility Programs and Man Pages Unix utilities are self-contained each is free to interpret its command-line arguments as it sees fit. This freedom is annoying instead of being able to learn a single set of conventions for command line arguments, you have to read a man page for each program to figure out how to use it. It’s a good thing the man pages are so well written. Take this following example. The “SYNOPSIS” sums it up nicely, don’t you think?

Programming in Plato’s Cave 183 LS(1) Unix Programmer's Manual LS(1) NAME ls - list contents of directory SYNOPSIS ls [ -acdfgilqrstu1ACLFR ] name ... DESCRIPTION For each directory argument, ls lists the contents of the directory for each file argument, ls repeats its name and any other information requested. By default, the output is sorted alphabetically. When no argument is given, the current directory is listed. When several arguments are given, the arguments are first sorted appropriately, but file arguments are processed before directories and their contents. There are a large number of options: [...] BUGS Newline and tab are considered printing characters in file names. The output device is assumed to be 80 columns wide. The option setting based on whether the output is a teletype is undesirable as “ls -s” is much different than “ls -s | lpr”. On the other hand, not doing this setting would make old shell scripts which used ls almost certain losers. A game that you can play while reading man pages is to look at the BUGS section and try to imagine how each bug could have come about. Take this example from the shell’s man page: