Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP
Path: utzoo!watmath!clyde!burl!we13!ihnp4!fortune!rpw3
From: rpw3@fortune.UUCP
Newsgroups: net.cog-eng
Subject: Re: Re: name=value or -n value - (nf)
Message-ID: <2853@fortune.UUCP>
Date: Tue, 27-Mar-84 04:03:52 EST
Article-I.D.: fortune.2853
Posted: Tue Mar 27 04:03:52 1984
Date-Received: Wed, 28-Mar-84 00:49:26 EST
Sender: notes@fortune.UUCP
Organization: Fortune Systems, Redwood City, CA
Lines: 69

#R:sdchema:-109400:fortune:29300005:000:3328
fortune!rpw3    Mar 26 21:28:00 1984

Well, THIS member of the option=value camp thinks environments
are fine and dandy, but...

Environments do o.k. at tagging options to command names, but what
happens when you want to tag an option to a specific file within
a command? No, you don't issue multiple commands, the side effects
are horrendous. Check out this example (from TOPS-10):

	.print/forms:letter *.dun/copies:2 *.let/cop:1 *.mem/cop:10

Thus, in ONE mounting (the operator puts down his/her magazine and goes over
to the printer and puts on the new forms, aligns them, etc., and does it again
when the next job prints on /forms:standard) of the quality bond-paper forms
("letter"), and ONE printer stream (so only ONE set of block letters eats
up special paper), prints 2 copies of all the dunning letters, one copy of
the normal letters, and 10 copies of the infernal internal memos. (Note that
option names and keyword values may be abbreviated to least-unique-prefix.)

Now that's been around in "10-land" for a decade. It works (on such 10's
as are left). We STILL can't do exactly that in UNIX-land (but see below).
Not griping -- PDP-10's had their own problems (like no "fork"!). But it's
just an example that people really did (do) use BOTH command-global switches
and file-local switches. VAX/VMS has equivalent syntax available.

However, if you allow position-sensitive options (*gasp*) in your command
syntax, and if you assume that ALL options are command-global through end
of line, and that options may be given MORE than once (*gasp again*) to
override a previous setting, you can duplicate the above command rather
naturally in UNIX, as follows (also assuming abbrev's are o.k.):

	$ print -forms=letter -copies=2 *.dun -cop=1 *.let -cop=10 *.mem

Note that (although the example doesn't show it) it is not necessary to
put the options in front of EVERY filespec, as long as the values didn't
change. "print -cop=3 *.dun *.let -cop=5 *.mem" prints 3 copies of both
the dunning and normal letters.

It's the old story: since I USED and LIKED the flexibility of both
command-global (which UNIX could, I suppose, do with "environment")
and file-local options, I would like to have them in UNIX. Having worked
with a standard command-parsing subroutine package (SCAN/WILD on the PDP-10),
I know that you CAN handle such syntax easily. It's just a matter of getting
used to the coding conventions.

SERIOUS PROPOSAL:  I claim that we need TWO standard scanners: one to do
"traditional UNIX" parsing (and that one should have EXACTLY the syntax and
semantics proposed by the AT&T standard) for any program for which it makes
sense (most of them); and, a TOPS-10/SCAN/WILD style (VAX/VMS if you prefer)
for those programs that NEED the wider range of flexibility.

In this case, I believe that two is NOT worse than one, for with only the
one "traditional" inflexible single-letter-option all-options-first, etc.,
everytime somebody can't fit that mold they will go off and invent yet
another "dd" or "find" or "sort" syntax.

With TWO blessed, supported (with "getopt" and "getoptx"?), documented
command syntaxes, the level of ad-hoc-ness can be made much lower.

Discussion?

Rob Warnock

UUCP:	{sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD:	(415)595-8444
USPS:	Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065