Comments on UNIX command option syntax

[Stanley Friesen]

In article <791 at whuxl.UUCP> mike at whuxl.UUCP (BALDWIN) writes:
>> Re: Stanley Friesen's comments about proposed UNIX command syntax standard.
>
><flame on>
>Oh, bug off!  The purpose of the syntax standard is to make things more
>uniform and easier to use.  Would you rather every command parses args
>differently for no good reason?? 

	I agree, but I think it could do this better than it does.
Uniformity is *nice*, but it can be carried too far. Actually you seem
to have misunderstood the purpose of my remarks. I was trying to
propose a few minor changes in the standard which I feel would improve
its utility and flexibility, without harming its value as a standard.
>
>The syntax standard DOESN'T PUT RESTRICTIONS on how you want to parse args;
>your program won't be silently removed if it doesn't adhere to it.  But if
>you want to be CONSISTENT and not have to tell people YET ANOTHER WAY TO
>PASS OPTIONS, then you can use getopt(3C) and not worry.

	Oh, I intend to use getopt(3C) as much as possible, but I
would hate to see it enforce *all* of the proposed rules. And yes the
full set of rules in the standard is restrictive, too restrictive. For
me to be willing to actually use the standard it would have to be much
less restrictive. As it stands, I will ignore the standard whenever it
is convenient to do so! It wi8ll not get very far as a standard, and
will not produce much uniformity, if loads of people ignore it as
being too restrictive. Whoever is in charge of it should rewrite it to
be more flexible.

>getopt to programs usually REMOVES restrictions; lots of programs do it
>one way or another (bundle/no_bundle, space/no_space), but not both because
>it is just a pain to take care of all the cases.
>
	Agreed, this is why I will probably use getopt(), but *not*
the syntax standard!

>There are always going to be commands that don't adhere to the standard,
>like cc, pr, and sort.  But that's OK.  The purpose of writing down the
>standard is that when you go to write a NEW command, you have something
>to aim for.

	Now, when I invent a new language, say 'Blaise', and write a
compiler for it(a NEW command) I must either cripple it by leaving
out the '-l' option capability, or violate the standard by allowing
post argument options with position dependent meaning! The standard
should include all *major* ways of using options in current comamnds.
I consider the compilers to be *major* commands, even though there are
only a few of them. The standard needs to include them!

> And it's not intended to be the best way ever to do option
>handling; it is meant to encapsulate the most prevalent means of option
>handling currently found in UNIX.
>
	And it misses, it fails to incorporaste the very commonly used
option handling syntax of every existing compiler on UNIX! Just
because it covers the syntax of the greatest *number* of seperate
commands does not mean it covers the syntax of the *most* *used*
commands. It needs to do *both*.

>It is NOT meant to encompass every single way options are dealt with in
>UNIX.  If it DID, it would be so vague and wishy-washy that it would be
>useless.
>
	Agreed, but see above, it misses some *important* current uses.

>Do YOU have a counter proposal?  If you do, I'd like to hear it.  It should
>NOT be radically different from the way things are done now.  I.e., programs
>like ls, cat, ed, grep, sed, etc., should be able to use it without any
>problems.

	Yes, I do have some suggestions, and I gave them in my
original article. To start with drop the rule about *all* option
preceding *all* arguments.

-- 

				Sarima (Stanley Friesen)

UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen
ARPA: ttidca!psivax!friesen at rand-unix.arpa