donn@sdchema.UUCP (03/25/84)
What has not been mentioned is that Unix DOES support a standard name=value syntax for passing information to programs: namely, the Bourne Shell syntax for assigning to environment variables. With the proper option decoder one could arrange to get either 'name=value' or '-n value' options, and without ambiguity -- 'name=value' appears to the left of the command, '-n value' to the right. You might imagine being able to issue a compile two ways: $ cc -O -DDEBUG -s -o foo foo.c or $ optimizer=on define=DEBUG strip=on output=foo cc foo.c In fact there would be several nice side effects to using environment variables for setting options. For example, environment variables can be sticky: $ mt -f /dev/rmt0 fsf 1 $ tar xvf /dev/rmt0 file $ mt -f /dev/rmt0 fsf 1 could instead be $ tape=/dev/rmt0 $ export tape $ mt fsf 1 $ tar xv file $ mt rew Another advantage is that environment variables are inherited -- if you are running a program which calls other programs, you can pass options to these subsidiary programs with environment variables. In the case of the C compile above, the compiler wouldn't have to make any special arrangements to pass 'strip=on' to the loader, unlike the current way things are done where an argument list must be re-formulated for each subprogram. And notice that the operating system and libraries and shell need not change to implement this scheme... Alas, some sort of consistent option parsing must be enforced. I doubt this will satisfy either faction, Donn Seeley UCSD Chemistry Dept. ucbvax!sdcsvax!sdchema!donn 32 52' 30"N 117 14' 25"W (619) 452-4016 sdcsvax!sdchema!donn@nosc.ARPA
dave@utcsrgv.UUCP (Dave Sherman) (03/26/84)
I like Donn's suggestion. However, there has to be a simple way of
examining the currently-set environment variables (they may have
been set in a .profile you don't know about, or several hours ago
on a long terminal session) which will be relevant to a particular
command.
Dave Sherman
Toronto
utcsrgv!dave
--
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsrgv!daverpw3@fortune.UUCP (03/27/84)
#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 94065guido@mcvax.UUCP (Guido van Rossum) (03/30/84)
This discussion seems to run away a bit. 'T is nice to know that the DEC-10/20 users are still listening to us, but I think that we should separate the design of a standard for option parsing (which we can do right now, with small steps in the desired direction) from a scheme where at any moment one can ask for a list of possibilities, etc. (I know the latter from Emacs, and like it very much; but it should be part of a *visual* interface, and there will be lots of problems before we have a universally accepted standard along the Unix lines. I don't think the ncsh program of which we got some examples would give the right answer to $ GREP C<?> or it would have to know an awful lot about what it's doing...) As for option syntax, the getopt parser and associated proposal are a step in the right direction that even the most conservative Unixophiles are willing to conform to. (PLEASE POST IT! A standard which can only be adopted by System N licensees is of no use to those writing software that is supposed to be portable to all V7 look-alike systems -- like myself.) Personally I agree with the person who said that bundling options is nice, but that having longer option names is nicer in the long run. This could be a gradual change, where only new programs allow longer option names (and abbreviations!) and bundling disappears slowly. I don't use bundling very often except for ls and programs (tar, ps) which require bundling. Actually I never implemented bundling in the many option parsers I have written myself during the years. On using environment variables: the general problem is probably that one option name can have meaning to lots of programs, and it is not at all clear that you want it set to the same value for all those. (Yes, of course this fact alone would cause better option names to be devised so that the same option name has the same meaning throughout the system; in fact we are doing this already with things such as EDITOR, TERM etc. But I wouldn't want 'verbose' to be set for all the programs I run, and I think the same is true for most commonly used option names. So it's not a general solution.) I don't believe that the Waterloo solution (+flag, -flag, opt=value) will make it in the Unix world -- not all sites can convert every program they acquire, and having a mix of two standards is worse than having no tight standard but at least one convention. -- Guido van Rossum, "Stamp Out Basic" Committee, CWI, Amsterdam guido @ mcvax
rjh@ihuxj.UUCP (Randolph J. Herber) (03/31/84)
TSS(tm-IBM) is an old operating system. It has "default" variables which are very similiar to Unix(tm-AT&T Bell Labs) environment variables. The problem that same variable (by name) may have different meanings to different programs is a significant (not necessarily major) problem. When the problem was looked into for TSS, it was suggested (by whom I do not know) to have qualified "default" variables with the understanding that unqualified variables were intending to be global. The scan would first look for a "default" variable qualified by the program name and then if not found, look for a global version of the "default" variable. Maybe a similiar solution would be useful for Unix. Randolph J. Herber, Amdahl Systems Engineer, ..!ihnp4!ihuxj!rjh, c/o IH 1C220, AT&T Bell Labs, Naperville, IL 60566, (312) 979-6554 or AT&T Cornet 8-367-6554, or Amdahl Corp., Suite 250, 6400 Shafer, Rosemont, IL 60018, (312) 692-7520