[net.bugs.usg] getopt

ptw@babel.UUCP (02/17/86)

As described in the man page, getopt(1) will erroneously be passed arguments
if any contain embedded IFS characters.  The correct invocation of getopt
should be:

	set -- `getopt <optstring> "$@"`

to preserve quoted args.  Unfortunately, getopt itself does not preserve
quoting.  The only "legitimate" way I could think of enhancing getopt to
preserve quoted args would be for it to single-quote each element of
its output string, requiring the following usage:

	eval set -- `getopt <optstring> "$@"`

Perhaps the re-quoting could be triggered by a quote char in optstring.

Q:  Does anyone use getopt?  Have they run into this problem?  Can anyone
suggest a better solution?

gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/03/86)

In a paper entitled "An Enhanced Getopt", T. C. Jones and L. A. Kennedy
of AT&T Bell Laboratories undertook an overhaul of getopt(1) and getopt(3C)
to support the Command Syntax Standard.  They proposed altering the usage
of getopt(1) from the current
	set -- `getopt ops $*`
to
	eval set -- "`getopt ops "$@"`"
in order to avoid the extra IFS argument splitting.  In order for this
proposal to work, a shell bug (handing of $@ when no arguments exist)
needs to be fixed.

Their proposal has one serious design botch, however:  The new form of
getopt(1) cannot be upward-compatible with the current version!  This
should be avoided by calling the new utility something like "getopts"
while continuing to provide a "getopt" with the old semantics during a
transition period.  I hope this mistake is fixed before we all end up
having our existing shell scripts break on "flag day".