Mail Archives: cygwin/2009/11/30/11:55:02
Cygwin 1.7 getopt has made some strides towards being more Linux-compatible,
but there are still a couple remaining bugs recently detected by the m4
testsuite.
On Linux, setting optind=0 forces a re-evaluation of getenv("POSIXLY_CORRECT");
this can be useful if a program wants to parse multiple argv sequences, and
calls either unsetenv("POSIXLY_CORRECT") or setenv("POSIXLY_CORRECT","",1) in
between the two sequences. But on cygwin, the environment is consulted only
once and cached; thereafter, there is no way to change the state of whether the
getopt engine will attempt posix compliance.
On Linux, there is an extension to POSIX of using "-" at the beginning of the
optstring argument to getopt to get it to parse all arguments in order until an
instance of "--" is encountered (with non-options appearing as if they were the
optarg of the invisible short-opt '\1'). Cygwin's getopt also supports this
extension, but only when POSIXLY_CORRECT is unset (and given the first bug,
there is no way to unset the POSIXLY_CORRECT state once getopt() has been
invoked at least once). Since a leading dash in the optstring is a pure
extension permitted by POSIX, the state of POSIXLY_CORRECT should not disable
the extension.
Here's an example of how the m4 testsuite caught this second bug (by the way,
m4 is one of the few exceptions explicitly mentioned in POSIX where options
must be parsed interspersed with file names, rather than the normal rule that
options stop on the first non-option):
On Linux or cygwin 1.5 (where there were enough other getopt bugs that m4 used
the glibc getopt):
$ echo foo > bar
$ m4 -Dfoo=1 bar -Dfoo=2 bar
1
2
$ POSIXLY_CORRECT= m4 -Dfoo=1 bar -Dfoo=2 bar
1
2
On cygwin 1.7 (where m4 tried to use cygwin's native getopt)
$ echo foo > bar
$ m4 -Dfoo=1 bar -Dfoo=2 bar
1
2
$ POSIXLY_CORRECT= m4 -Dfoo=1 bar -Dfoo=2 bar
m4: cannot open `-Dfoo=2': No such file or directory
I don't know if either of these bugs have been fixed in the upstream BSD
sources that cygwin borrowed from, or if we also need to raise a BSD bug
report. But it does seem rather ironic that setting POSIXLY_CORRECT actually
breaks POSIX compliance of m4 argument parsing.
--
Eric Blake
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -