Xref: utzoo comp.lang.c:9330 comp.unix.wizards:7788
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!nrl-cmf!cmcl2!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: <7687@brl-smoke.ARPA>
Date: 14 Apr 88 21:44:18 GMT
References: <2414@zyx.UUCP> <8039@elsie.UUCP> <7628@brl-smoke.ARPA> <143@gsg.UUCP> <7680@brl-smoke.ARPA> <2585@ttrdc.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 15

In article <2585@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
># >':' is special-cased in getopt.c.  Look at the code.
>Have I made myself clear[er]?

Yes, you're correct that AT&T's getopt() implementation doesn't support
a ":opts" third argument, even though neither : nor ? is disallowed by
the command syntax standard rules.  Since the interface spec for getopt()
gives a special meaning to '?' but not to ':' return, it is clear that
no conforming getopt() implementation could support a ? option.  It is
not so clear that none could support : (which could also be specified
via "x::yz"), but at least we now know that AT&T's (which is the one
presumably everyone actually uses) doesn't.  I must say it surprises me..

If anyone thinks we're nit-picking, they're right.  I suspect very few
getopt()-using applications use anything other than letters of the
alphabet (in either case) for valid option designators.