bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]

2013-01-22 Thread Marcel Böhme
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)

bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]

2013-01-22 Thread Pádraig Brady
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

bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]

2013-01-22 Thread Pádraig Brady
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

bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]

2013-01-22 Thread Stefano Lattarini
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

bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]

2013-01-22 Thread Bernhard Voelker
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

bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]

2013-01-22 Thread Pádraig Brady
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 ||

bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]

2013-01-22 Thread Pádraig Brady
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

bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]

2013-01-22 Thread Bernhard Voelker
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.