Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!cs.utexas.edu!sm.unisys.com!ism780c!patrick
From: patrick@ism780c.isc.com (Patrick Curran)
Newsgroups: comp.unix.wizards
Subject: Re: friendly messages
Message-ID: <22569@ism780c.isc.com>
Date: 21 Feb 89 22:02:41 GMT
References: <435@laic.UUCP> <955@auspex.UUCP> <9218@bloom-beacon.MIT.EDU> <5734@bsu-cs.UUCP> <90507@sun.uucp>
Reply-To: patrick@ism780c.UUCP (Patrick Curran)
Distribution: usa
Organization: Interactive Systems Corp., Santa Monica CA
Lines: 41

In response to various amusing comments about VMS's tendency to keep you
over-informed about what it's doing:
========

While I'm no great fan of VMS, I did spend a couple of years working with
it, and I really must correct the (mis)impressions that are being
generated here.

Yes, VMS's messages can be irritatingly wordy.  However, it is possible
to customize the message system to behave the way you want it to.  I
forget the precise details, but essentially there are several sorts of
messages (informational, warning, error, system?), and each message has
several components (a number, an identification of the program which
issued the message, an indication of its type, and the message itself).

It's possible to specify that you only want particular types of messages
to be displayed, and/or that you only want to see particular message
components.  Consequently, if you want nothing but UNIX-style terse error
messages (no fluff, no warnings, no informational messages) you can get
them.  If you want more, you can have that too.

(Now that I think of it, if you're from the "real hackers don't need
error messages" school, you could turn off all messages, so implementing
the ultimate in silent systems :-)

The advantage of the centralized error-message-handler is that user-
written or third-party programs can utilize its capabilities, inserting
their own messages into the database.  All (well-written) programs
therefore behave in exactly the same way.  Similar capabilities exist for
adding user-supplied help messages to the system help database, and for
accessing the command-line parsing capabilities of the CLI.

The result is a much cleaner interface; users know how to invoke
programs, how to get help while using them, and how to interpret the
messages they produce.  Sounds to me like a big win over the current
state of affairs in the UNIX world.  The sooner we implement something
similar, the sooner we'll be taken seriously in the real world where
people run applications rather than hack software.

Patrick Curran (uunet!ism780c!patrick)
INTERACTIVE Systems Corp, Santa Monica, CA. (213) 453-8649