getopt(3) posting FLAME

[Curtis Jackson]

In article <306 at graffiti.UUCP> peter at graffiti.UUCP (Peter da Silva) writes:
>[getopt] does the wrong thing. It can't even handle the arguments that
>sort(1) (V7) uses, to wit:
>
>	sort -mubdfincrtx
>
>Where the final 'tx' means 'tab character <x>'. The rest of sort's arguments
>are even less parsable by getopt. There is no reason for getopt's
>insistence on lots of whitespace, nor for its ignoring argument order, nor
>for its inability to handle '+' and '-' type command flags...

All this is based in getopt from AT&T Unix Sys III and up:

Agreed that getopt cannot handle '+' type command flags, BUT -- it can indeed
handle the trailing tx mentioned above, it ignores whitespace between switches
that do not require arguments, and it does NOT ignore argument order.  Sounds
to me like you have an inferior, 'non-standard' getopt.

>do the same thing, allows more flexibility (foo -s -g:; foo -s -g :; foo -sg:;
>foo -sg :), and produces a program that needs less core. If you think that's
>a minor consideration, remember why vi doesn't use stdio on a PDP-11.

Again, 'real' getopt will accept all of the above combinations of -s and -g
above.  Agreed, it does add somewhat to the size of your program -- but since
I write microassemblers and compilers that generally have 15-20 command-line
switches I don't really mind -- it buys me a lot of clarity.  Also, I am on
a Vax 11/780 with 10 meg main memory   :-)
-- 

The MAD Programmer -- 919-228-3313 (Cornet 291)
alias: Curtis Jackson	...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj
			...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj