GNU bug report logs - #13525
8.20 - [seq 1 3 1] treated as [seq 1 3]

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13525 in the body.
You can then email your comments to 13525 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Marcel Böhme" <hawkie <at> web.de>
To: bug-coreutils <at> gnu.org
Subject: 8.20 - [seq 1 3 1] treated as [seq 1 3]
Date: Tue, 22 Jan 2013 11:43:14 +0100 (CET)

Dear all,

There is another bug that sneaked into the speed patch of seq on 13.09.12:

560   if (all_digits_p (argv[optind])
561       && (n_args == 1 || all_digits_p (argv[optind + 1]))
562       && (n_args < 3 || STREQ ("1", argv[optind + 2]))
563       && !equal_width && !format_str && strlen (separator) == 1)

That should probably be:
560   if (all_digits_p (argv[optind])
561       && (n_args == 1 || all_digits_p (argv[optind + 1]))
562       && (n_args < 3 || STREQ ("1", argv[optind + 1]))
563       && !equal_width && !format_str && strlen (separator) == 1)

Best regards,
 Marcel

Message #10 received at 13525-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Marcel Böhme <hawkie <at> web.de>
Cc: 13525-done <at> debbugs.gnu.org
Subject: Re: bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]
Date: Tue, 22 Jan 2013 11:23:22 +0000

[Message part 1 (text/plain, inline)]

On 01/22/2013 10:43 AM, Marcel Böhme wrote:
>
> Dear all,
>
> There is another bug that sneaked into the speed patch of seq on 13.09.12:
>
> 560   if (all_digits_p (argv[optind])
> 561       && (n_args == 1 || all_digits_p (argv[optind + 1]))
> 562       && (n_args < 3 || STREQ ("1", argv[optind + 2]))
> 563       && !equal_width && !format_str && strlen (separator) == 1)
>
> That should probably be:
> 560   if (all_digits_p (argv[optind])
> 561       && (n_args == 1 || all_digits_p (argv[optind + 1]))
> 562       && (n_args < 3 || STREQ ("1", argv[optind + 1]))
> 563       && !equal_width && !format_str && strlen (separator) == 1)

Sigh we really messed up seq in that release :(
The attached should fix it:

I also notice another regression,
which I'll fix in a moment.

 $ seq 0 1 0
 0
 1

thanks,
Pádraig.

[seq-ignored-step.diff (text/x-patch, attachment)]

Message #13 received at 13525 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 13525 <at> debbugs.gnu.org, P <at> draigBrady.com, hawkie <at> web.de
Subject: Re: bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]
Date: Tue, 22 Jan 2013 13:16:45 +0100

On 01/22/2013 12:23 PM, Pádraig Brady wrote:
> On 01/22/2013 10:43 AM, Marcel Böhme wrote:
>>
>> Dear all,
>>
>> There is another bug that sneaked into the speed patch of seq on 13.09.12:
>>
>> 560   if (all_digits_p (argv[optind])
>> 561       && (n_args == 1 || all_digits_p (argv[optind + 1]))
>> 562       && (n_args < 3 || STREQ ("1", argv[optind + 2]))
>> 563       && !equal_width && !format_str && strlen (separator) == 1)
>>
>> That should probably be:
>> 560   if (all_digits_p (argv[optind])
>> 561       && (n_args == 1 || all_digits_p (argv[optind + 1]))
>> 562       && (n_args < 3 || STREQ ("1", argv[optind + 1]))
>> 563       && !equal_width && !format_str && strlen (separator) == 1)
> 
> Sigh we really messed up seq in that release :(
> The attached should fix it:
> 
One minor typo in commit message:

> [SNIP]
>
> * tests/misc/seq.pl: Add a test foro this case.
>
s/foro/for/

Regards,
  Stefano

Message #16 received at 13525 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: 13525 <at> debbugs.gnu.org, hawkie <at> web.de
Subject: Re: bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]
Date: Tue, 22 Jan 2013 12:17:33 +0000

[Message part 1 (text/plain, inline)]

On 01/22/2013 11:23 AM, Pádraig Brady wrote:
> On 01/22/2013 10:43 AM, Marcel Böhme wrote:
>>
>> Dear all,
>>
>> There is another bug that sneaked into the speed patch of seq on 13.09.12:
>>
>> 560   if (all_digits_p (argv[optind])
>> 561       && (n_args == 1 || all_digits_p (argv[optind + 1]))
>> 562       && (n_args < 3 || STREQ ("1", argv[optind + 2]))
>> 563       && !equal_width && !format_str && strlen (separator) == 1)
>>
>> That should probably be:
>> 560   if (all_digits_p (argv[optind])
>> 561       && (n_args == 1 || all_digits_p (argv[optind + 1]))
>> 562       && (n_args < 3 || STREQ ("1", argv[optind + 1]))
>> 563       && !equal_width && !format_str && strlen (separator) == 1)
>
> Sigh we really messed up seq in that release :(
> The attached should fix it:

Updated patch attached.

thanks,
Pádraig.

[seq-ignored-step.diff (text/x-patch, attachment)]

Message #19 received at 13525 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 13525 <at> debbugs.gnu.org, hawkie <at> web.de
Subject: Re: bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]
Date: Tue, 22 Jan 2013 13:28:13 +0100

On 01/22/2013 01:17 PM, Pádraig Brady wrote:
> Updated patch attached.

That one is looking good ... but while we're at it:

Anyone tried this, i.e. a Zero as INCREMENT?

  $ seq 1 0 2

This is equal to `yes 0`. Well, this is probably a (not
documented) feature, but in the following examples, the "1"
should be printed only once, shouldn't it?

  $ seq 1 0 1
  $ seq 1 0.0 1

(BTW: "seq 2 0 1" works, i.e. doesn't print anything.)

Have a nice day,
Berny

Message #22 received at 13525 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: 13525 <at> debbugs.gnu.org, hawkie <at> web.de
Subject: Re: bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]
Date: Tue, 22 Jan 2013 12:59:19 +0000

[Message part 1 (text/plain, inline)]

On 01/22/2013 12:17 PM, Pádraig Brady wrote:
> On 01/22/2013 11:23 AM, Pádraig Brady wrote:
>> On 01/22/2013 10:43 AM, Marcel Böhme wrote:
>>>
>>> Dear all,
>>>
>>> There is another bug that sneaked into the speed patch of seq on 13.09.12:
>>>
>>> 560   if (all_digits_p (argv[optind])
>>> 561       && (n_args == 1 || all_digits_p (argv[optind + 1]))
>>> 562       && (n_args < 3 || STREQ ("1", argv[optind + 2]))
>>> 563       && !equal_width && !format_str && strlen (separator) == 1)
>>>
>>> That should probably be:
>>> 560   if (all_digits_p (argv[optind])
>>> 561       && (n_args == 1 || all_digits_p (argv[optind + 1]))
>>> 562       && (n_args < 3 || STREQ ("1", argv[optind + 1]))
>>> 563       && !equal_width && !format_str && strlen (separator) == 1)
>>
>> Sigh we really messed up seq in that release :(
>> The attached should fix it:

The seq 0 1 0 "regression" was only because I didn't
adjust for the parameters passed into seq_fast.

So hopefully this update caters for all cases.

thanks,
Pádraig.

[seq-ignored-step.diff (text/x-patch, attachment)]

Message #25 received at 13525 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 13525 <at> debbugs.gnu.org, hawkie <at> web.de
Subject: Re: bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]
Date: Tue, 22 Jan 2013 13:24:30 +0000

On 01/22/2013 12:28 PM, Bernhard Voelker wrote:
> On 01/22/2013 01:17 PM, Pádraig Brady wrote:
>> Updated patch attached.
>
> That one is looking good ... but while we're at it:
>
> Anyone tried this, i.e. a Zero as INCREMENT?
>
>    $ seq 1 0 2
>
> This is equal to `yes 0`. Well, this is probably a (not
> documented) feature, but in the following examples, the "1"
> should be printed only once, shouldn't it?
>
>    $ seq 1 0 1
>    $ seq 1 0.0 1
>
> (BTW: "seq 2 0 1" works, i.e. doesn't print anything.)

Yes I was wondering that myself.

Though I suppose that `seq 0 0 1` prints endlessly,
means that it's consistent that as long as start <= end
and step == 0, then start is printed endlessly.

Maybe we should special case to only print
the start value once if step = 0.
Maybe one could use a step of 0 to hack a
min/max function or something?

  min() { minv=$(seq "$1" 0 "$2"); : ${minv:="$2"}; echo $minv; }
  max() { minv=$(seq "$1" 0 "$2"); : ${maxv:="$1"}; echo $maxv; }

Though I'm stretching here as that could be done
(albeit with 3 processes) like:

  min() { printf '%s\n' "$@" | sort -rg | tail -n1; }
  max() { printf '%s\n' "$@" | sort -g | tail -n1; }

cheers,
Pádraig.

Message #28 received at 13525 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 13525 <at> debbugs.gnu.org, hawkie <at> web.de
Subject: Re: bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]
Date: Tue, 22 Jan 2013 14:47:01 +0100

On 01/22/2013 02:24 PM, Pádraig Brady wrote:
> Yes I was wondering that myself.
> 
> Though I suppose that `seq 0 0 1` prints endlessly,
> means that it's consistent that as long as start <= end
> and step == 0, then start is printed endlessly.

Yes, from a mathematical point of view, seq is right.
Therefore, maybe documenting seq's behavior would suffice.
OTOH ...

> Maybe we should special case to only print
> the start value once if step = 0.

... users may not be amused about an endless loop in a tool
which is otherwise meant for counting, e.g.

  $ seq $start $step $last | \
  while read x ; do work_on $s ; done

Stopping after the start valie is maybe not mathematically
correct, but more "natural".

> Maybe one could use a step of 0 to hack a
> min/max function or something?
>
>    min() { minv=$(seq "$1" 0 "$2"); : ${minv:="$2"}; echo $minv; }
>    max() { minv=$(seq "$1" 0 "$2"); : ${maxv:="$1"}; echo $maxv; }

TBH this doesn't look like as if a normal user would be
able to invent this. ;-)

Have a nice day,
Berny

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.