-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I found a regression in m4 on cygwin 1.7, and traced it to the fact that getopt.m4 no longer rejects BSD getopt even though it still has bugs compared to GNU getopt_long.
Cygwin 1.7 is currently using getopt.c with the following header: /* $OpenBSD: getopt_long.c,v 1.23 2007/10/31 12:34:57 chl Exp $ */ /* $NetBSD: getopt_long.c,v 1.15 2002/01/31 22:43:40 tv Exp $ */ This version of getopt.c has support for optind=0 implying a reset. However, it is buggy, in that POSIXLY_CORRECT is queried exactly once; whereas in GNU, optind=0 is a sign that POSIXLY_CORRECT must be re-queried from the environment. So, in applications (such as test-getopt) that call getopt_long, then change the environment, then call getopt_long again, the state of whether POSIX behavior will be used is erroneously locked down to the prior behavior. The second is that when POSIXLY_CORRECT is set, but the option string begins with '-', BSD erroneously stops parsing at the first non-option, rather than treating all non-options as arguments to option '\1'. For comparison, a build of m4 with gnulib getopt does: $ touch a $ m4 -d a -d $ POSIXLY_CORRECT= m4 -d a -d $ But with BSD getopt: $ touch a $ m4 -d a -d $ POSIXLY_CORRECT= m4 -d a -d m4: cannot open `-d': No such file or directory $ In other words, BSD no longer realizes that -d is still an option. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksP/T4ACgkQ84KuGfSFAYDaXACeOTWTJv6M/yP639BJw8lZfpov z4YAoM+u4AxX7NWvMQ5w0DGthZKiXqb8 =gqFA -----END PGP SIGNATURE-----
