It's time to bump this thread.
How was your week? Have you had a good reading?

UNIX: The World's First Computer Virus

This chapter has four topics:

• UNIX as an evolutionarily successful virus.
  
• UNIX as an economically successful drug.
  
• Standardization.
  
• UNIX myths.
  

The chapter begins by comparing UNIX with an evolutionarily successful virus. It explains that the reason for its success was not because UNIX was technically superior, but because, like a virus, it was evolutionarily superior.

Both virus and UNIX share the following characteristics: they are small (minimal, don't have too much in it), portable (can (invade) be ported to different types of hosts), requires attention of the host to be succeed, and are able to mutate very quickly.

The chapter than tells the story of the UNIX, praising how MULTICS was designed to be good while UNIX was not. It also explains how, like a virus accumulates random genetic material, UNIX accumulated random bloat software.

IIRC from TUPE, # and @ were used as line editing commands in old terminals. The chapter also cites it as one of UNIX accumulated genetic material.

The chapter now goes to another metaphor: UNIX as a drug. Now, another reason for UNIX success was, again, not because it was technically superior, but because, like drugs, it was economically superior.

On the topic of standardization, the chapter says that users want a Standard UNIX, but vendors don't want it. They want to stick the user with their own version of UNIX, in order to avoid competition.

Quote:I think UNIX and snowflakes are the only two classes of objects in the Universe in which no two instances ever match exactly.

The result of the lack of uniformity among UNIXes is the effect of throwing #ifdefs at the code.

Quote:I don't know if there's a moral to this story, other than one should never trust anything related to UNIX to be compatible with any other thing related to UNIX.

It cites the standards: POSIX, X/Open, CORBA(?) and even OpenStep.

The chapter closes talking about the UNIX myths. As drug users lie to themselves (“pot won't make me stupid”, “I can stop anytime I want to”, etc), UNIX users lie to themselves too. UNIX has its own collection of myths:

• It's standard (now it is, kinda).
  
• It's fast and efficient (yes, it is).
  
• It's the right OS for all purposes (well, there are not other options...).
  
• It's small, simple, and elegant (I believe the UNIX I'm using is indeed).
  
• Shell scripts and pipelines are great way to structure complex problems and systems (I agree it's not the greatest or most elegant way, it's more like a glue).
  
• It's documented online (when it is documented...).
  
• It's documented (except when it isn't).
  
• It's written in a high-level language (I cannot opine on that as C is the only language I know well).
  
• X and Motif make UNIX as user-friendly and simple as the Macintosh (now we have Qt and Gtk!)
  
• Processes are cheap (now they are (but I still have to replace some fork(2)s with a bloated single process some times)).
  
• It invented the hierarchical file system, electronic mail, networking and the Internet protocols, remote file access, security/passwords/file protection, finger, uniform treatment of I/O devices (if it hadn't invented them, it at least popularize them).
  
• It has a productive programming environment (yeah, it hasn't, the environment is left for the user to set it).
  
• It's a modern operating system.
  
• It's what people are asking for (it's what I asked for).
  
• The source code is available (now it is, and for free as in freedom!), understandable (except if you use GNU stuff). And what you buy from your manufacturer actually matches what you are running (not applicable).
  

Welcome New User: Like Russian Roulette with Six Bullets Loaded

This chapter goes on how UNIX is not newbie-friendly. It has six points that defends that:

• Cryptic command names.
  
• rm(1) accidents (it has long texts for this topic).
  
• Inconsistency (yeah, I admit, it still annoys me).
  
• Documentation (the next chapter deals more about it).
  
• Error messages.
  
• The UNIX (philosophy) attitude.
  

Unlike the LISP world of verbose-command-names, UNIX way of naming things is quite cryptic (two letter commands). It cites as a footnote one situation in which Ken Thompson was asked what he would have changed about UNIX if he had it all to do over again (He would spell “creat(2)” with an “e”). I remember this story from TUPE (page 204).

The chapter then goes on a long text full of examples on how rm(1) can be destructive, irreparable and irreversible.

Quote:UNIX abuses our trust by steadfastly refusing to protect its clients from dangerous commands. In particular, there is rm(1), that most dangerous of commands.

It reckons some reasons why files die more often under UNIX than under any other operating system:

• The UNIX file system lacks version numbers (solved on plan9).
  
• Unix programmers have a criminally lax attitude toward error reporting and checking (I must admit, I do that).
  
• The UNIX shell, not its clients, expands “*”.
  
• File deletion is forever.
  

I have a trash(1) command that moves files into a XDG-compliant trash directory and an untrash(1) command that move files back. But I must admit that I always forgot to use them, and keep deleting important stuff. If you are interested in those scripts, here they are.

There is a mail that this chapter quotes that occurred EXACTLY to me:
In my keyboard the greater-than (>) character is the shifted period (.) and to type an asterisk (*) I have to keep shift pressed. So I miscalculated the timing and kept shift pressed from the asterisk when I was typing a period, so instead of rm *.o, I typed rm *>o. Curiously, the “o” file isn't deleted.

The book then says how permanently and irreversibly deleting important data with rm(1) is considered by comp.unix.questions' FAQ as a rite of passage in the UNIX environment. Hehe.

Now the book goes to the inconsistencies in UNIX, that, I must admit, annoys me.

Quote:Predictable commands share option names [not on UNIX. -v is verbose or version? -h is human-readable or help?], take arguments in roughly the same order [have you used find(1) today?], and, where possible, produce similar output [Let's not talk about ps(1) output].

Indeed, Macintosh had a user-interface standard (for its graphical interface), as did NeXT, but the command line interface is the wild west. There is no common standard other than the oral tradition.

Quote:No such body has ever existed for UNIX utilities. As a result, some utilities take their options preceded by a dash, some don't. Some read standard input, some don't. Some write standard output, some don't. Some create files world writable, some don't. Some report errors, some don't. Some put a space between an option and a filename, some don't.

Quote:The highest achievement of the UNIX-aesthetic is to have a command that does precisely one function, and does it well. Purists object that, after freshman programmers at Berkeley got through with it, the program “cat” which concatenates multiple files to its output now has OPTION

And thus the cat-v movement was born.

The chapter reckons some flaws of UNIX way of handling arguments:

• (1) The * wildcard is expanded by the shell, not by a library by the program.
  
• (2) Options (switches) and other arguments should be separate entities, as they are in DOS.
  
• (3) UNIX filenames are permissible (tabulation, dash, and EVEN NEWLINES are tolerated).
  

[opinion]
Although I understand the simplicity of giving programs their post-processed calling command, we cannot deny that it is inconsistent how programs parse their argument. Not all of them use getopt(3). Some cannot use it.
I think that rather than passing argc and argv, passing an actual structure with pre-parsed options would avoid the need to call getopt(3) and would keep things more regular.
[/opinion]

The chapter discuss a little more about possible and impossible filenames, and tells the story that some “UNIX victims” turn the filename-as-switch bug into a “feature” by keeping a file named “-i” in their directories:

Quote: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.

I have never heard about this. Sounds terrible.

Some commands use dashes to indicate “please ignore all following dashes”. This is a bad solution, in my opinion.

Online documentation.
More on the next chapter.

The chapter then goes to the topic of error messages, and how UNIX refuses to give them. This section ends with a set of error jokes, most of them not applicable in modern systems.

It then summarizes the chapter:

Quote:We've painted a rather bleak picture: cryptic command names, inconsistent and unpredictable behavior, no protection from dangerous commands, barely acceptable online documentation, and a lax approach to error checking and robustness.

And of course, the chapter shills on the UNIX philosophy.

Documentation: What Documentation?

This chapter's topic is the UNIX documentation, the man pages, which, second the author, are “nothing more than a collection of reminders for people who already know what they are doing”, and that use “a set of text formatting macros used for nothing else on the planet”.

One of the first complaints about man pages is the lack of hyperlinking.

Quote:Today's hypertext systems let you jump from article to article in a large database at the click of a mouse button; man pages, by contrast merely print a section called “SEE ALSO” at the bottom of each page and invite the user to type “man something else” on the command line following the prompt.

There was an alternative to man pages that uses hyperlinking: GNU info pages. But nobody likes GNU info pages. I think that a SEE ALSO section with only related man pages is better than the hyperlink hell other documentation systems may have.

The chapter then talks about SystemV man page directory system (/usr/man/c_man). I had no idea of the existence of such a thing. Thank goodness I have never found it in any system I have used.

It then shows a mail about the quest of a user to find the location of a man page.

Then, the chapter talks about the lack of man pages to shell built-in commands. I think that the number sectioning system is bad. Named sections would be more helpful. For example, “man bin/awk” for binaries, “man lib/printf” for system and library calls. This setting could be even expanded with “man bin/awk/printf” to get the manual of a builtin command of a shell (or of awk).

The chapter then goes on internal usage notices some programs have. Some of them have a “-h” option to show usage, or show the usage when no argument is given. But again, this is inconsistent.

Then, the chapter reveals that the actual documentation is the source code, as man pages generally reveals nothing useful. It talks about NeXT file system hierarchy structure, with /NextDeveloper/Headers as a path for included headers. Damn, the file system structure was a wild west back in the days. Binaries in /lib, headers in different directories scattered all over the place...