Consistently Inconsistent 27 OPTIONS. (“Cat came back from Berkeley waving flags,” in the words of Rob Pike, perhaps the ultimate Unix minimalist.) This philosophy, in the hands of amateurs, leads to inexplicably mind-numbing botches like the existence of two programs, “head” and “tail,” which print the first part or the last part of a file, depend- ing. Even though their operations are duals of one another, “head” and “tail” are different programs, written by different authors, and take different options! If only the laws of thermodynamics were operating here, then Unix would have the same lack of consistency and entropy as other systems that were accreted over time, and be no better or worse than them. However, archi- tectural flaws increase the chaos and surprise factor. In particular, pro- grams are not allowed to see the command line that invoked them, lest they spontaneously combust. The shell acts as an intermediary that sanitizes and synthesizes a command line for a program from the user’s typing. Unfortu- nately, the shell acts more like Inspector Clouseau than Florence Nightin- gale. We mentioned that the shell performs wildcard expansion, that is, it replaces the star (*) with a listing of all the files in a directory. This is flaw #1 the program should be calling a library to perform wildcard expansion. By convention, programs accept their options as their first argument, usu- ally preceded by a dash (–). This is flaw #2. Options (switches) and other arguments should be separate entities, as they are on VMS, DOS, Genera, and many other operationg systems. Finally, Unix filenames can contain most characters, including nonprinting ones. This is flaw #3. These archi- tectural choices interact badly. The shell lists files alphabetically when expanding “*”, and the dash (-) comes first in the lexicographic caste sys- tem. Therefore, filenames that begin with a dash (-) appear first when “*” is used. These filenames become options to the invoked program, yielding unpredictable, surprising, and dangerous behavior. Date: Wed, 10 Jan 90 10:40 CST From: kgg@lfcs.ed.ac.uk (Kees Goossens) Subject: Re: rm * Newsgroups: alt.folklore.computers 6Using “cat” to type files to your terminal is taking advantage of one of its side effects, not using the program for its “true purpose.”

28 Welcome, New User! Then there’s the story of the poor student who happened to have a file called “-r” in his home directory. As he wanted to remove all his non directory files (I presume) he typed: % rm * … And yes, it does remove everything except the beloved “-r” file… Luckily our backup system was fairly good. Some Unix victims turn this filename-as-switch bug into a “feature” by keeping a file named “-i” in their directories. Type “rm *” and the shell will expand this to “rm -i filenamelist” which will, presumably, ask for confirmation before deleting each file. Not a bad solution, that, as long as you don’t mind putting a file named “-i” in every directory. Perhaps we should modify the mkdir command so that the “-i” file gets created auto- matically. Then we could modify the ls command not to show it. Impossible Filenames We’ve known several people who have made a typo while renaming a file that resulted in a filename that began with a dash: % mv file1 -file2 Now just try to name it back: % mv -file2 file1 usage: mv [-if] f1 f2 or mv [-if] f1 ... fn d1 (‘fn’ is a file or directory) % The filename does not cause a problem with other Unix commands because there’s little consistency among Unix commands. For example, the file- name “-file2” is kosher to Unix’s “standard text editor,” ed. This example works just fine: % ed -file2 4347 But even if you save the file under a different name, or decide to give up on the file entirely and want nothing more than to delete it, your quandary remains: 7The “434” on the line after the word “ed” means that the file contains 434 bytes. The ed editor does not have a prompt.