Short options with arguments conflicts with AllowHyphenValues #3410
Labels
A-parsing
Area: Parser's logic and needs it changed somehow.
C-enhancement
Category: Raise on the bar on expectations
E-medium
Call for participation: Experience needed to fix: Medium / intermediate
Please complete the following tasks
Clap Version
3.0
Describe your use case
The program GNU
seq
requires us to parse floating point values as arguments, which may be negative or have formatting different from the standard<f64 as FromStr>
style. At the same time it accepts some short options to control the output. The problematic case is combining those two: we must utilizeAllowHyphenValues
while also accepting short option values.$ seq -s, -1 2 -1,0,1,2 $ # Demonstrating non-f64-style arguments that must also match positional values: $ seq -0x.ep-3 -0x.1p-3 -0x.fp-3 -0,109375 -0,117188
This is solved in GNU by external iteration over the arguments where
seq
itself decides what constitutes a flag, and what starts the value arguments: https://github.com/coreutils/coreutils/blob/master/src/seq.c#L593-L604In clap, however, when
AllowHyphenValues
is active then only short options character are allowed to appear in an option. Otherwise, it is interpreted as a position argument. Seeclap/src/parse/parser.rs
Lines 994 to 995 in 5c3868e
Describe the solution you'd like
Now, I would propose to add a new setting that slightly modifies these rules. Where an hyphenated argument may start with short options but where short option parsing stops at the first value-taking option, and any other characters are permitted when such an option is recognized. That is, in this context, where the short options
w
ands
exist,-ws,
would be interpreted as:w
matches a short option without argument, continue.s
matches a short option that does take an argument, switching to value mode because this option takes a value.-
is ignored as part of the value.-ws,
is interpreted as options.Alternatives, if applicable
A more intricate solution would be to enable external iteration, where arguments are consumed by clap one-by-one. That is, more like the GNU style parsing loop where some
get_first_argument(iterator)
consumes only some arguments from the iterator but returns control to the caller after the first option has been consumed. This could enable an iteration loop in the style of GNUseq
where the arguments are pre-tested by the program logic on whether they constitute a positional argument; allowing us to break manually instead of requireAllowHyphenValues
to controlclap
to do this internally.Additional Context
The text was updated successfully, but these errors were encountered: