Xref: utzoo comp.lang.c:8736 comp.unix.wizards:7483
Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: command line options
Message-ID: <7596@brl-smoke.ARPA>
Date: 31 Mar 88 10:57:32 GMT
References: <2414@zyx.UUCP> <1988Mar30.233142.2040@utzoo.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 17

In article <1988Mar30.233142.2040@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>This one seems to have fallen down the crack between them, actually.
>It's definitely not in X3J11, and it wasn't in POSIX the last time I looked.

My understanding is that IEEE 1003.2 is expected to deal with getopt
or equivalent.

>One should also remember, for better or worse, that getopt is a de facto
>standard.  (An official one, if you believe in the SVID.)

getopt also evolved out of a Bell Labs study by Hemenway and Armitage
of the existing UNIX command options.  It was designed to be the best
compromise common-ground facility, even though it was acknowledged that
a totally different option syntax might be an improvement.  It probably
ought not to be foisted off on non-UNIX systems, but it makes a lot of
sense to use it for most UNIX utilities.  Many times I've been saved
just by having "--" supported.