GNU bug report logs -
#29617
seq: `seq 1 --help' doesn't give help
Previous Next
To reply to this bug, email your comments to 29617 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#29617
; Package
coreutils
.
(Fri, 08 Dec 2017 17:45:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
chadweisman <at> nym.hush.com
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Fri, 08 Dec 2017 17:45:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
We should be able to put the options anywhere and not necessarily before any arguments. And even if not (e.g. POSIX conformance overrides,) --help should be handled specially to conform to the GNU coding standards. [1]
1. https://www.gnu.org/prep/standards/standards.html#g_t_002d_002dhelp
cheers,
Chad.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#29617
; Package
coreutils
.
(Fri, 08 Dec 2017 18:56:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 29617 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 12/08/2017 11:38 AM, chadweisman <at> nym.hush.com 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.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#29617
; Package
coreutils
.
(Sun, 18 Feb 2018 18:42:01 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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
[coreutils-seq-bug-29617.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#29617
; Package
coreutils
.
(Tue, 20 Feb 2018 01:36:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 29617 <at> debbugs.gnu.org (full text, mbox):
On 18/02/18 10:41, chadweisman <at> nym.hush.com 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.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#29617
; Package
coreutils
.
(Tue, 20 Feb 2018 01:44:01 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2/19/2018 at 8:35 PM, "Pádraig Brady" <P <at> draigBrady.com> wrote:
>
>On 18/02/18 10:41, chadweisman <at> nym.hush.com 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.
>
Wow, did I ever! Sorry for that.
>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.
>
I also tried a two-pass approach but it ended up being pretty messy. I can't help but think using argp would make this particular problem easier to handle.
Chad
[coreutils-seq.patch (application/octet-stream, attachment)]
Added tag(s) confirmed and patch.
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Tue, 30 Oct 2018 02:20:02 GMT)
Full text and
rfc822 format available.
Changed bug title to 'seq: `seq 1 --help' doesn't give help' from '`seq 1 --help' doesn't give help'
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Tue, 30 Oct 2018 02:20:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 177 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.