From: Robin H. Johnson Date: Tue, 05 May 2009 20:21:16 GMT Subject: Re: [PATCH] Fix sloppy Getopt::Long. Message-ID: In-Reply-To: <7vfxfj1gu9.fsf@alter.siamese.dyndns.org> On Tue, May 05, 2009 at 12:37:34PM -0700, Junio C Hamano wrote: > "Robin H. Johnson" writes: > > > Getopt-Long v2.38 is much stricter about sloppy getopt usage. The > > trailing pipe causes git-svn testcases to fail for all of the --stdin > > argument calls. > > I am not objecting at all; just asking for clarification. > > > - { 'stdin|' => \$_stdin, %cmt_opts, %fc_opts, } ], > > + { 'stdin' => \$_stdin, %cmt_opts, %fc_opts, } ], > > Is this "pipe" supposed to be followed by an alternative spelling of the > option, as in > 'stdin|standard-input' => \$_stdin, ... Yes. Short form or alternative long form. > and is the sloppyness that it would be crazy to accept either --stdin or > just -- (without actual option name) for this option? Within the main loop, both '--' and '-' are treated as special cases earlier on before the matching of options is done. '--' is the explicit separator, while '-' is an argument (or a value to an option), not an option in itself. > Could an older version of Getopt::Long() have accepted > > $ command --foo --bar - other args > > to set $_stdin to true with that "sloppy" syntax? If so people could have > relied on such a behaviour, which is a bit worrying. As far as I can follow in the Getopt::Long code, with the old case of 'stdin|', the empty string case would never have matched anyway. The v2.38 change in respect to this is not described in the upstream CHANGES, but boils down to this single modification: Getopt-Long-2.38/lib/Getopt/Long.pm: @@ -777,7 +776,7 @@ # Option name (?: \w+[-\w]* ) # Alias names, or "?" - (?: \| (?: \? | \w[-\w]* )? )* + (?: \| (?: \? | \w[-\w]* ) )* )? -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85