friendly messages

[Guy Harris]

>Cryptic is in the eye of the beholder. Consider a voice-communications
>system which required you to type in 7 to 10 digit strings to
>establish virtual circuits! AT&T has done fairly well with this
>design, and it's not obvious that any change would be for the better.

Yes, at times I've noticed the annoying similarity between the error
messages UNIX coughs up and the error messages the phone system coughs
up....  Whilst a change to the scheme for dialing may or may not
represent an improvement, other aspects of the phone system *could* be
changed in ways that, at least from the end-user's viewpoint, would be
for the better.

One example is the moral equivalent of the "syntax error" message.  You
know, the one that starts with that horrible shriek (which, I seem to
remember hearing, is required by some standard, so that one may not be
AT&T's fault), and then informs you that "your call cannot be completed
as dialed".

This is about as annoying as, say, the "foo: alpha/beta/gamma: cannot open"
messages that UNIX programs tend to cough up.  A change that is
obviously for the better is to have those messages print out the error
message associated with "errno", so you don't have to try an "ls" to see
if the file doesn't exist, or exists but doesn't let you read it, or....

The moral equivalent of such a change to the phone system user interface
would be for it to tell you something like "that call's in your area
code, dummy, leave the area code off!"  An even better change would be
for it to ignore the area code; I don't know whether either change is
possible - it may well not be, and it may be too expensive to change the
phone system to support it, and may have been too expensive to built the
phone system to support it.  The same isn't true of UNIX; using "perror",
or using "sys_nerr" and "sys_errlist", isn't that costly.

(Also, going back to the original point, consider a networking system
that required you to type in N-digit strings to specify host addresses
in individual configuration files for various network services; a change
that centralized the host-name-to-address mapping and let all the
services use that mapping, so that their configuration files could have
names, would be a change for the better.)

>The most amazing part of any technology are the people who use it,
>be careful when playing armchair psychologist.

Well, I *have* used UNIX and the phone system, and yes, there are places
in both where the cryptic error messages simply suck.  Ever tried
debugging a long "ed" script with a version of "ed" that *cannot* be
told to print long error messages? I made the SunOS 4.0 "ed" print *line
numbers* when it's in "long error messages" mode - as turned on by the
"H" command, since that "ed" is derived from the S5R3 "ed" - and was
given the "-" option.  That made it *lots* easier to debug big "ed"
scripts such as the ones used when building the S5R3 "curses" library. 

People too often seem to take it for granted that short, cryptic error
messages are ultimately a Good Thing under all circumstances and that
UNIX has nothing to learn or to improve in this regard.  It's simply not
true.  (Why did not "ed" print TECO-style short error messages instead
of just "?"?   As I remember, DEC TECO printed error messages with a "?"
followed by a 3-letter code, or maybe vice versa.  Terse, but at least
it doesn't throw away information....)

None of this is to say that VMS-style error messages necessarily
represent an improvement, just that there *is* plenty of room for
improvement in UNIX's error messages.  (At least we no longer have
botches such as "ar" printing its error messages to standard output;
well do I remember doing "ar t foo.a | lpr" and getting one sheet of
printout saying "foo.a does not exist"....)