Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!utcs!lsuc!pesnta!hplabs!hao!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.works
Subject: Re: grisly grizzled programs
Message-ID: <3284@umcp-cs.UUCP>
Date: Sat, 16-Feb-85 00:35:58 EST
Article-I.D.: umcp-cs.3284
Posted: Sat Feb 16 00:35:58 1985
Date-Received: Sun, 17-Feb-85 12:35:38 EST
References: <596@topaz.ARPA> <372@terak.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 27

Ok, let's actually take this real example of "ls" bugs (4.2BSD manual):

	Newline and tab are considered printing characters in file names.

Now seriously, how often do you find file names with newlines and tabs
in them?  Has *anyone* ever *really wanted* ls to print \n or \t?

	The output device is assumed to be 80 columns wide.

Fixed in ours.  (Reads termcap.)  (Or at least it did under 4.1; I don't
know if I ever reinstalled that change.)

	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.

This one even *explains* why this is done this way.  The "shell scripts
which used ls" are *user* programs; there's not much Berkeley can do
about those.  This "bug" entry really just explains (in a poor sort of
way) why you should use -C all the time....

The Unix manuals have their problems, but the "BUGS" entry is a feature. :-)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland