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".