Mail Archives: cygwin/2009/11/30/12:48:25
On Nov 30 16:54, Eric Blake wrote:
> 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.
Bugs? Linux-incompatibilities, ok, but bugs?
> 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.
That's still the case in the upstream OpenBSD sources.
A fix based on these sources would be simple, though.
> 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
Which makes sense, given that this is a GNU extension and not POSIXly
correct.
> (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.
I disagree. Or rather, I agree with the BSD sources here. The in-order
scanning of the arguments should only be supported if POSIXLY_CORRECT is
not set. I don't see the special allowance for a leading dash in optstring
anywhere in the POSIX getopt man pages.
> 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.
It's not a bug per se. POSIX doesn't specify this behaviour so I don't
see how this qualifies as a bug. The NetBSD sources show that the
developers are aware of the fact that glibc's getopt is handling the
in-order scanning independently of POSIXLY_CORRECT, but they didn't
align the behaviour to that so far.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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 -