GNU bug report logs -
#23110
seq apparent bug
Previous Next
Reported by: Маренков Евгений <hotpil <at> mail.ru>
Date: Thu, 24 Mar 2016 17:23:03 UTC
Severity: normal
Tags: fixed
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):
On Thursday 07 April 2016, Bernhard Voelker wrote:
> tags 23110 notabug
> close 23110
> thanks
>
> On 04/06/2016 08:19 PM, Ruediger Meier wrote:
> > This sounds all true, however then these one should also run
> > forever: $ seq 10 0 2
> >
> > Man page says:
> > INCREMENT is usually positive if FIRST is smaller than LAST,
> > and INCREMENT is usually negative if FIRST is greater than
> > LAST.
> >
> > This implicates IMO that seq should try to count _down_ if FIRST >
> > LAST and INCREMENT=0
>
> Admittedly, the above documentation aims at useful constellations
> where seq really operates as a sequence generator - maybe the wording
> around "... usually ..." could be improved here.
>
> In this case, it's not a matter of how increment is treated, but more
> when seq ends - which is documented quite clearly both in the --help
> output (and therefore in the generated man page), and in the Texinfo
> manual:
>
> http://www.gnu.org/software/coreutils/seq
>
> The sequence of numbers ends when the sum of the current number
> and increment would become greater than last, [...]
>
> > Moreover I'd say this one does not need to loop endless:
> > $ seq 0 0 0
>
> Why? The sum of 0+0 will never become _greater_ than 0.
> Likewise for the OPs case ("seq -w 2 0 10"): the sum will never
> become greater than 10.
>
> Thus saying, I think this issue is more a confusion regarding the
> expectations from the tool. I don't see why an increment of 0 should
> be treated special here.
>
> Therefore, I'm marking this issue as "not a bug", and closing it.
> As always, further discussion may continue here, and we can re-open
> this issue if needed ... especially if someone proposes a better
> wording for the above documentation snippet. ;-)
I understand that this issue is not a bug. But it wouldn't be also not a
bug if coreutils would behave like BSD:
$ seq 1 0 10 ; echo $?
seq: zero increment
1
This is much more useful and safe. Scripts which invoke an endless loop
by using seq have almost certainly made something wrong. Endless loop
and 100% CPU usage could be avoided.
People who _want_ endless trivial "sequences" are using yes(1).
cu,
Rudi
This bug report was last modified 6 years and 210 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.