[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#23110: seq apparent bug
From: |
Ruediger Meier |
Subject: |
bug#23110: seq apparent bug |
Date: |
Thu, 7 Apr 2016 10:46:10 +0100 |
User-agent: |
KMail/1.9.10 |
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
- bug#23110: seq apparent bug, Ruediger Meier, 2016/04/06
- bug#23110: seq apparent bug, Bernhard Voelker, 2016/04/07
- bug#23110: seq apparent bug,
Ruediger Meier <=
- bug#23110: seq apparent bug, Bernhard Voelker, 2016/04/07
- bug#23110: seq apparent bug, Pádraig Brady, 2016/04/08
- bug#23110: seq apparent bug, Paul Eggert, 2016/04/08
- bug#23110: seq apparent bug, Ruediger Meier, 2016/04/08
- bug#23110: seq apparent bug, Paul Eggert, 2016/04/08
- bug#23110: seq apparent bug, Ruediger Meier, 2016/04/09
- bug#23110: seq apparent bug, Bernhard Voelker, 2016/04/09
- Message not available
- bug#23110: seq apparent bug, Bernhard Voelker, 2016/04/14
- bug#23110: seq apparent bug, Pádraig Brady, 2016/04/14
- bug#23110: seq apparent bug, Bernhard Voelker, 2016/04/14