bug#23110: seq apparent bug

[Ruediger Meier]

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