[net.cog-eng] hang vol_ser=123456 file=mytape mode=read_write density=1600

idallen@watmath.UUCP (03/13/84)

> From dave@utcsrgv.UUCP (Dave Sherman) Fri, 9-Mar-84 13:52:22 EST
> 
> As Mark Callow points out, that's hardly UNIX-like. 
> ...
> hang -w -s 800 mytape
> 		(put a write ring in, and mount for 800bpi)

Unlike your UNIX-like syntax, the given syntax needed no explanation.
-- 
        -IAN!  (Ian! D. Allen)      University of Waterloo

dave@utcsrgv.UUCP (Dave Sherman) (03/14/84)

~|  From: idallen@watmath.UUCP
~|  Subject: hang vol_ser=123456 file=mytape mode=read_write density=1600
~|  > From dave@utcsrgv.UUCP (Dave Sherman) Fri, 9-Mar-84 13:52:22 EST
~|  > 
~|  > As Mark Callow points out, that's hardly UNIX-like. 
~|  > ...
~|  > hang -w -s 800 mytape
~|  > 		(put a write ring in, and mount for 800bpi)
~|  
~|  Unlike your UNIX-like syntax, the given syntax needed no explanation.

I know. If I want explanation I'll look at the manual. The same
goes for all other UNIX commands. If you're going to introduce
a new command to UNIX, you should keep its syntax reasonably like
that of other UNIX commands. If you want to type all that drivel
every time you type any command, use some other operating system
(or write yourself a shell that takes all those options, looks them
up in the manual, and calls "hang -w -s 1600 123456").

Seriously, if you can't remember all the options, you should be
able to type "hang" alone and get a list. I'm sure none of us
can really remember the arguments to /etc/mknod - so what?
We get our devices configured somehow.

Unrepentant,

Dave Sherman
-- 
 {allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsrgv!dave

brad@looking.UUCP (Brad Templeton) (03/15/84)

I find objection to this syntax on the grounds that it isn't unix a
bit questionable.  There is almost nothing consistent in the syntax
of unix commands.
Why do people tolerate "dd", which has a syntax like this?
Why do some commands use dashes for their options, while others like
tar, dump and ps use just the letters?  Why do half the commands
have a syntax -b value and the others use -bvalue?
Why do sort, uniq and vi have options specified with a "+"?
Why do some commands allow options anywhere on the line and others
only at the beginning?

Suggesting you can type a command with no args and get a usage line is
total ****.  Many commands do things when typed alone, and some that
don't still don't give usage lines.  (QNX has a system that if absolutely
no args are given (argc==0) then you give a usage line, and the shell has
a means to call routines like this -> "command ?" so that is a consistent
system, but don't say unix has one.)

The syntax used at waterloo is a lot easier to remember and has been designed
so that the same option (ie. file= ) has the same name and syntax on every
command.  Furthermore, there is an abbreviator that allows options like
mode=read to be typed as m=read if that is unambiguous.
-- 
	Brad Templeton - Waterloo, Ontario (519) 886-7304

paul@dual.UUCP (Baker) (03/18/84)

Yes, it's one of the many obnoxious features of UN*X that to get a feature
for most programs you need '-' something or other.  To any sane person
'-' something would tend to mean that the feature would be revoked not
invoked.  Another related gripe is that, even though the overpriced C
programmers bible says that the order of command line parameters should
not be important, it almost always is, even in very frequently used
programs such as 'ls'.  It complains bitterly if '-last' occurs after
the filename(s).  The form of command line listed in the Subject line
is inherently insensitive to order, much like the DEC TOPS-10 method of
submitting command parameters.

		Paul

guy@rlgvax.UUCP (Guy Harris) (03/18/84)

The usage of "-" as the option indicator character in UNIX dates back to
Multics, which made the same choice.  DEC operating systems use "/", and
the reason why UNIX can't use this is left as an exercise to the reader...
Multics' path name syntax used ">", so they could have used "/"; the reason why
UNIX couldn't use ">" is also left as an exercise (Multics also used "<" to
move up in the hierarchy, in the same way UNIX uses "../").  "+" might be
preferable, although it's slightly more inconvenient to type (it's shifted,
while "-" isn't).  Stratus also uses "-" as the option indicator, but
considering one of Stratus' founders is the guy who wrote the Multics PL/I
compiler, the fact that Stratus' OS was written in PL/I and resembles a
certain MIT/Honeywell/Bell Labs sort of product should be obvious...

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy

idallen@watmath.UUCP (03/19/84)

The B Programming Language and environment distributed by Honeywell and
written by the U of Waterloo Software Development Group started out using
"-" to indicate options without values, and kwd=value for options with
values.  Several years ago, it changed to use both "+" and "-" for options.
"+" turns the option on, e.g. +warnings or +w; "-" turns it off. 

I was concerned about the extra shift for the "+", but after using it for
a while, I find it's good.  Options are full words.  This means it's
easy to see what an option does when you spell it out, but it means you can't
bunch options together (-alxww) like some (sigh) UNIX commands allow.

Whatever the syntax, the two best features of the B Environment are the
use of full words for options and the fact that everything is the
*same*.  The same option word means the same thing in every command.
The position of options with respect to arguments is almost always unimportant.
"lc idallen -catalogs +files" and "lc -catalogs +files idallen" are identical.

Waterloo has both B and C library routines that let a programmer just
fill in a table of option words and corresponding variables -- the
routine does all the command line parsing and sets the variables for you.
-- 
        -IAN!  (Ian! D. Allen)      University of Waterloo

idallen@watmath.UUCP (03/21/84)

X
    Unlike your UNIX-like syntax, the given syntax needed no explanation.
      -me (IAN!)

    The VMS/MVS syntax needs an explanation too. One needs to explain
    why he or she is trying to hang something so gadawfully verbose
    and JCL-ish on top of UNIX.
      -Ian F. Darwin

I thought that was clear -- to make it easier for people to understand
what the option flags mean, by giving them word-names instead of letters.

Comments on command-language mnemonics from people using UNIX as their
life's work aren't very useful; anyone with that much exposure to the
system will always have the time and motivation to learn any command
names and any option flags.  The UNIX command language is obviously
suited to intensive users; but because they are intensive users, they
don't really care what the commands are called as long as it's not
"verbose".  My favourite idea -- let each letter of the alphabet stand
for a highly-used UNIX command name.  Now *that* would be in the UNIX
tradition: "p -laxwwt01", "n -T37 -ms -rd1 -o15", "u", "l -las", etc...

What seems silly, now that less intensive users have their hands on
UNIX, is that UNIX chose to give the commands and options themselves
names that are *abbreviations*.  (Though what "x" is an abbreviation
for in "ps -laxwwt01" isn't clear.)  Even if the newcomer can somehow
remember that s/he must REMOVE a UNIX file (and not DELETE it or ERASE
it), s/he has to remember that REMOVE is abbreviated RM.

My argument is simple -- when you first learn a system, you want to
remember the command and optiona names.  It's easier to remember words
than abbreviations.  When you find yourself using a command a lot, then
*and only then* do you want to abbreviate it.  No need to make people
remember abbreviations for names and options right away.

And if you do use full words in names and options, you seldom have to
look past the first few lines in the MAN page to see which option you
want, because the options are spelled out and give a hint to their meaning:

    Syntax:
	process_status (ps) [ option... ] [ process_id... ]
    Options:
	+All +Verbose Tty=xx +Wide +Userids +Running +Notty

instead of (and I quote):

	ps [ acegklrstuvwx# ]
-- 
        -IAN!  (Ian! D. Allen)      University of Waterloo