command line arguments

[John Quarterman]

From: <jsq at ut-sally.UUCP> John Quarterman (moderator)

Topic: getopt (command line arguments) continued

This looks like it is going to be a backburner discussion for some time.

It has been noted in mail that the other getopt than the one I posted
may be superior, and that it would be good to post whichever is the best
to mod.sources or net.sources again, as those get archived on many hosts.
Negotiations are in progress.

Note the address for submissions to mod.std.unix is ihnp4!ut-sally!std-unix.
Mark Horton is very efficient, but he's got his own newsgroups to moderate....

----------------------------------------------------------------------

Date: Wed, 3 Jul 85 16:51:43 edt
From: wfmans at ihuxb.uucp
Subject: Re: command line arguments
To: mark at cbosgd.ATT.UUCP
References: <2220 at ut-sally.UUCP>

> > some commands take arguments as
> > 
> > command -abcdefg filename
> > 
> > and some as
> > 
> > command -a -b -c -d -e -f -g filename
> > 
> > It would be great if this was standardised.
> 

The thing that burns me about some commands (and these are usually
experimental tools, mind you, real UNIX commands seem to work ok)
is that while most will accept
command -flag           and        command - flag
some will only accept one or the other.
I suppose that its easier to process the latter with a shell script
if you don't use getopt, but it sure is a pain.

------------------------------

Date: Wed, 3 Jul 85 12:58:16 cdt
From: neuro1!baylor!peter at rice.uucp (Peter da Silva)
Subject: Re: Re: command line arguments
Newsgroups: mod.std.unix
To: neuro1!mark at cbosgd.ARPA
References: <2210 at ut-sally.UUCP> <2226 at ut-sally.UUCP>

:-) Look! No quotes!

I doubt the necessity and even the wisdom of seperating an argument from
the option by whitespace. I also dislike the blackballing of multicharacter
options.

Since no arguments are allowed to be optional there's no point in
distinguishing between '-t/dev/tty4' and '-t /dev/tty4'. Since 't'
requires an argument the parsing is unambiguous.

It makes it harder to write transparent shell scripts. Atomic options make
it much easier to pass stuff onto other programs. Parsing options in shell
scripts is pretty much a lossage anyway, so why make things harder?

As for multicharater options: do you intend to kill "tail -30"? Since
changing the number of lines is the most common case what's the problem?
At any rate you should allow a simple '-nnn' for a high-usage.

[ Since tar is the standard for data interchange (actually, only the
format of the tar data, not the tar program, is currently in the draft
standard), I suspect there will always be anomalies.  The advantage
of getopt is not that it's perfect, just that it's close enough and
widespread enough that it has some chance of being adopted everywhere.
 -mod ]

----------------------------------------------------------------------

The moderated newsgroup mod.std.unix is for discussions of UNIX standards,
in particular of the draft standard in progress by the IEEE P1003
"UNIX Standards" Committee.

Submissions to the newsgroup to:	ut-sally!std-unix
Comments about the newsgroup to:	ut-sally!std-unix-request
Permission to post to the newsgroup is assumed for mail to the former address,
but not for mail to the latter address, nor for mail to my personal addresses.
-- 

John Quarterman, jsq at ut-sally.ARPA, {ihnp4,seismo,ctvax}!ut-sally!jsq