On 18/02/18 10:41, [email protected] wrote: > >> On 12/08/2017 11:38 AM, Eric B wrote: >>> Hello, >>> >>> I am using coreutils version 8.27 on Fedora, and I don't see this fixed in >>> 8.28's NEWS. >>> >>> $ seq 1 --help >>> seq: invalid floating point argument: ‘--help’ >>> Try 'seq --help' for more information. > >> Interesting bug! > >>> >>> We should be able to put the options anywhere and not necessarily before >>> any >>> arguments. > >> Yes, when possible. > >>> And even if not (e.g. POSIX conformance overrides,) > >> POSIX does say you have to write 'foo -- --help' if you want to >> guarantee that --help is treated as a literal argument rather than >> option, but it also says that the moment you specify '--help' (or any >> other parameter starting with two dashes without the -- end-of-options >> parameter), you are already in undefined territory. So we can do >> whatever we want when encountering '--help' - which is part of the >> reason WHY the GNU project prefers making 'foo args --help' print help >> output where possible. > >>> --help should be handled specially to conform to the GNU coding standards. >>> [1] > >> Yes. > >> But the reason that it fails is because we use getopt_long(..., >> "+f:s:w") - where the leading '+' specifically requests that we NOT >> allow option reordering. Why? Because 'seq' is MOST useful if it can >> parse negative numbers easily. We deemed it more important to support >> 'seq 2 -1 1' without requiring the user to write 'seq -- 2 -1 1' - but >> in doing so, it also means that we can't reorder options, so any obvious >> non-option (like '1' in your example) makes all other parameters >> non-options (including '--help' in your example). > >> It might be possible to do a two-pass parse over argv: one that looks >> just for --help (and where treating -1 as an option is a no-op), and the >> second that actually parses things in order now that it knows --help is >> not present. But that's a lot of code to add for a corner case, so I >> won't be writing the patch; but I also won't turn it down if someone >> else wants to write the patch. > > Hello, > > I've taken a stab at fixing this problem because it affects me fairly often. > > Instead of using a two-pass system, I check if any of the args we scan are > --help or --version and bail if we see either. See attached patch. > > The bad side of this approach is that the -f, -s, and -w options and their > associated long options aren't handled so `seq 1 -w 2 10` still shows an > error. Also, it's a kludgy sort of fix, so I completely understand why you > wouldn't want to include it. But at least it's a step in the right direction > to give help when we can instead of an error. > > Chad >
Thanks for looking at this again. You attached the wrong patch. A helper function to prescan argv to look for --help and call usage() or --version and call version_etc(), while bailing itself if it encounters '--', does seem useful to have in seq. Though note it probably shouldn't support abbreviations like --h etc. BTW other commands that use '+' with getopt() to exist option processing early are tr, basename, pathchk, printf. Though all those could interpret --option as a valid argument and so wouldn't be appropriate to treat like this. Likewise for all the commands the exec, like chroot, env, ... as --options are very often passed to the delegate commands. cheers, Pádraig.
