eric@whuxlb.UUCP (08/31/83)
#R:sdcsvax:-370800:whuxlb:33800002:000:1035
whuxlb!eric Aug 30 20:12:00 1983
adding input flags to allow the user to get more
verbose output is NOT a valid solution to the
interactive problem of UNIX...because the more flags
there are, the more intimidating it is for the novice
(and indeed the expert) user. . . . . . Perhaps if
the routines defaulted to a interactive "help"
interface, then the flags could turn it off to a
varying degree...
PLEASE.... NO.... NO HELP FILES.... I like Unix to be terse. I
LIKE having to ask for verboseness. EVERY (general user) type program
I write usually has flags for verboseness. Like it or not, Unix was
written BY and FOR programmers. If you must, write your own little
commands to be verbose, but when I type ls in an empty directory, by
golly I DON'T WANT IT TO SAY ***ANYTHING***. Terseness is a virtue,
especially on slow (i'm talking 300 baud) terminals..
Cogito ergo computo, et ergo sum.
Eric Holtman (harpo!whuxlb!eric)
WH 1c-352d, x4890janc@uofm-cv.UUCP (08/31/83)
It seems like the best way to add a verbose option to Unix would be to have a standard $VERBOSE environment variable that would let you set the help level given by all commands. Level 0 would be normal ultra-terse Unix, 1 would ask permission to clobber files and so on, 2 would give you helpful hints and suggestions. This seems better than having to tell each command individually how much help you want, though there should be a way to override the environment help level locally. Jan D. Wolter University of Michigan
guy@rlgvax.UUCP (Guy Harris) (09/01/83)
Perhaps UNIX systems should provide a variety of user interfaces, as they
definitely aren't just for programmers anymore. However, for all the the
flak UNIX gets for its user interface it's not clear that most other
*comparable* systems are better by all that much. Would you say that CP/M's,
or RSX-11's, or TOPS-10's "PIP" is less "cryptic" than UNIX's "cp"? (Yes, I
know that DEC's command languages have picked "COPY" for the copy command
now.) Perhaps UNIX's command language isn't the nicest in the world, but
are most of the comparative systems *that* much better? If not, perhaps
the criticisms should be levelled equally at all such systems. Then again,
there was some research at Bell Labs that indicated that the difference
in "user-friendliness" between "cp" and "copy" didn't amount to much, if
anything - users could pick up whatever the "local" name for a command was
in a short period of time. I suspect what's referred to as the "principle
of least surprise" is more important; keep your command language reasonably
self-consistent (e.g., if the "-v" flag means "verbose" in most commands try
to make it mean that in as many commands as possible) and consistent with
some fairly straightforward model of the world (i.e., a "copy" command which
took the input file as "/INPUTFILE=xxx" and prompted you for the output file
might be poor).
Complete and *obligatory* terseness is *not* a virtue. The pre-UNIX/TS "ed"
which had *no way* of explaining an error message was not the right way to
do things, 300 baud terminal or no. Many editors which were used at 300 baud
had more helpful error messages. One idea which TECO had and which appears
in the current "ed" is that the editor can either output long error messages
or it can output short ones and you can ask for an explanation of the last
error. If you have to look at the past 20 lines of output to figure out
why something went wrong (i.e., because a program is *always* silent about
missing files) that's not a good idea. (And "pr"s "Very funny." error
message is amusing to those who know what's so funny but insulting to those
who don't.)
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy