GLD does not warn about ambiguous option

[dod38fr]

Hello

I have a set of options specified with:

   ...
      [ "force-load!"        => "Load file even if error are found in data. Bad data are discarded"],
      [ "file=s"             => "Specify a target file"],
   ...
    { getopt_conf => [ qw/no_bundling/ ] }

But GLD does not warn when command line is used with -f option. My program runs as if no option was specified. On the other hand -fi and -file options work as expected.

Getopt::Long has a different behavior: a warning message is shown to user when an option is ambiguous.

All the best

[n1vux]

Related, we have a script with several successive authors, in a GLD standardized project, that now has two options among many:

  [ "tab|t=i%" => ...
  ... many others ...
  [ "text|t" => ... some debug option rarely used ...

(Aside: Given that neither of these is what -t normally means in our scripts, so one might sensibly suggest neither should have had a default at all, but then I wouldn't have information to add here.)
It is not immediately clear if GLD set both the {tab} hash and the {text} flag, or just the flag, but it neither warned of the ambiguity, nor did resolve the ambiguity and do solely what was obviously intended (-t 1=1 would be the {tab} one that takes values for a hash not -t for --text).
Unlike the OP, whose GL warning is conditioned on receiving an ambiguous implicit/default abbrev option at runtime, I'd expect describe_options to throw a warning at least, if not croak ourright, on finding such explicit ambiguity between @opt_spec elements' requested abbrevs.
(But yeah, if it hurts when i do that, don't do that. :-) )
Anyway, we do like the module. It's like VMS arg handling without the rest of VMS, win.

[rjbs]

I agree that something should be done. given test|t and toast|t, I would hope for an error as early as possible. I may fix that myself in the future.

I am unlikely to fix how anything behaves when the getopt options are changed, though. In reality, I've been daydreaming about writing a replacement that totally bypasses Getopt, just to avoid any configuration being possible. :-)

[n1vux]

On Thu, Jan 28, 2016 at 7:45 PM, Ricardo Signes [email protected]
wrote:

​Thanks for feedback.​

I am unlikely to fix how anything behaves when the getopt options are

changed, though. In reality, I've been daydreaming about writing a
replacement that totally bypasses Getopt, just to avoid any configuration
being possible. :-)

[ ​To be clear, when i say "changed" i meant a later pull-request adding
features to the script-file (without reading carefully what prior
features used for options), accumulating options from multiple
source-files by injection, inheritance, or what-ever. ]

​ Bill​