Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site boring.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!mcvax!boring!guido
From: guido@boring.UUCP
Newsgroups: net.works,net.flame
Subject: Re: grisly grizzled programs (actually: comments on ls bugs)
Message-ID: <6322@boring.UUCP>
Date: Sun, 17-Feb-85 13:58:22 EST
Article-I.D.: boring.6322
Posted: Sun Feb 17 13:58:22 1985
Date-Received: Wed, 20-Feb-85 09:27:47 EST
References: <596@topaz.ARPA> <372@terak.UUCP> <3284@umcp-cs.UUCP>
Reply-To: guido@mcvax.UUCP (Guido van Rossum)
Organization: "Stamp Out BASIC" Committee, CWI, Amsterdam
Lines: 30
Xref: linus net.works:662 net.flame:7454
Summary: 
Apparently-To: rnews@mcvax.LOCAL

In article <3284@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes:
>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?

This is a clear specimen of the attitude which makes Unix still look so much
like what it originally was: a programmers' toy.  Programs that ignore lines
longer than 256 characters, core-dump on illegal input, ignore invalid flag
arguments, run exponentially slow for large input (due to a bad algorithm,
not the problem's nature), leave the terminal in a strange state when
interrupted, incredibly complex calling conventions, undocumented options
that are used by everybody, mysterious incantations in one's .profile,
und, und...  These are abundant in most versions of Unix.

This may be acceptable in a system that's mostly used by experts who wrote
it themselves and "just want their job done", it's not in Unix as it is
currently used: a user-friendly time-sharing system, or a powerful personal
computer's OS.  It is more than time that the programmers realize this and
start writing programs that can stand whatever the users do with them --
the program should either perform well or produce an understandable diagnostic.
Of course we can't write bug-free programs, but when a bug is discovered it
should be fixed, and not replied to with phrases like the above.

(BTW, ls should print '?' for \n and \t.  I suppose it's a two-line change.
Chris, this is your chance to be able to boast "fixed in our version..."
-- which was completely beside the point the original author made. :-)

	Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam
	guido@mcvax.UUCP