Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!decwrl!decvax!ima!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.unix.wizards
Subject: Re: Must UNIX be a memory hog?
Keywords: TZ, uucp LCK... files
Message-ID: <2@minya.UUCP>
Date: 17 May 89 20:47:51 GMT
References: <159@zebra.UUCP> <1608@auspex.auspex.com>
Organization: (none)
Lines: 31

In article <1608@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes:
> If you really want to get fanatical about wasted disk space, worry about
> the "true" command; it doesn't need to contain any data, but on more
> recent versions of System V, for example, it contains an AT&T copyright
> notice (right, they've copyrighted the null sequence of bytes; give me a
> break).  Multiply *that* by the number of UNIX systems with that style
> of "true" command, and just *imagine* what a *huge* chunk of the GNPs of
> the world's nations are being *wasted* on that! :-) :-) :-) :-) :-)

A minor legal quibble:  If you look at /bin/true, you will find that it
actually contains a blank line, which is an executable statement.  This
is what they are actually copyrighting.  So if you sell any shell script
that contains a blank line, you are in violation of AT&T's copyright.

On this system, as on several others, I've replaced /bin/true and /bin/false
with executables (which will be left as an exercise for the reader, since
posting them would be an intellectual insult to any True Unix Wizards ;-).
I've verified that the result is a measurable speedup in "while true"
loops, due to the elimination of the shell startup to run an empty script.
But this isn't much of a big deal, since such loops are rather rare.
For example, try adding a line to /bin/true that appends a byte to some
file every time it is called, and watch how fast the file grows.  You
will probably be disappointed.  If you're not, then replace /bin/true
right away.  In fact, why don't you do it now - the time it takes will
eventually be recovered in faster system response time.

-- 
John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)

[Any errors in the above are due to failures in the logic of the keyboard,
not in the fingers that did the typing.]