GNU bug report logs - #23110
seq apparent bug

Previous Next

Package: coreutils;

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


View this message in rfc822 format

From: Ruediger Meier <sweet_f_a <at> gmx.de>
To: 23110 <at> debbugs.gnu.org
Cc: mail <at> bernhard-voelker.de, hotpil <at> mail.ru
Subject: bug#23110: seq apparent bug
Date: Wed, 6 Apr 2016 19:19:27 +0100
On Thursday 24 March 2016, Bernhard Voelker wrote:
> On 03/24/2016 04:28 PM, Маренков Евгений wrote:
> > I have recently noticed an apparent bug in 'seq'. If one runs
> > seq -w 2 1 10
> > everything works fine.
> > But
> > seq -w 2 0 10
> > falls into endless loop ...
>
> Thanks for the report.
> However, I don't think this is a bug but more a misunderstanding
> on your side how seq works.  It's clearly documented that the
> second number (if 3 are given) is the increment.  As you passed
> 0 as value, the target 10 is never reached, and therefore seq
> continues to produce output.  Thus, it exactly does what you
> told it to do.  What else would you expect?

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

Moreover I'd say this one does not need to loop endless:
$ seq 0 0 0


BTW maybe it would be an improvement to handle epsilon related endless 
loops like this
$ seq 1 0.00000000000000000000000000000001 2


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.