tags 23110 fixed
close 23110
stop
(triaging old bugs)
On 2016-04-14 11:19 a.m., Bernhard Voelker wrote:
On 04/14/2016 06:47 PM, Pádraig Brady wrote:
The 2 patches look good.
thanks for the review, pushed.
closing as "fixed".
-assaf
On 04/14/2016 06:47 PM, Pádraig Brady wrote:
> The 2 patches look good.
thanks for the review, pushed.
> On 14/04/16 17:37, Bernhard Voelker wrote:
seq 1 .001 1
>> I consider this a bug in seq: from mathematical point of view, the above
>> should just output "1
The 2 patches look good.
On 14/04/16 17:37, Bernhard Voelker wrote:
>seq 1 .001 1
I consider this a bug in seq: from mathematical point of view, the above
should just output "1" and then exit, because after adding that tiny number
the next number would be greater
On 04/07/2016 08:18 PM, Pádraig Brady wrote:
> I agree that we should avoid repeating output with "0" STEP.
Thanks. I improved the error diagnostic by outputting the original
value from the user:
[PATCH 1/2] seq: do not allow 0 as increment value
> Do we want to deal with these cases spinning t
On 04/08/2016 09:45 PM, Paul Eggert wrote:
> On 04/08/2016 05:57 AM, Pádraig Brady wrote:
>> Do we want to deal with these cases spinning the cpu,
>> in further patches?
>>
>>seq 1 nan 1
>
> NaN should be an error in any of the operands.
+1
>> seq 1 .001 1
>
> Fo
On Saturday 09 April 2016, Paul Eggert wrote:
> On 04/08/2016 01:51 PM, Ruediger Meier wrote:
> > On Friday 08 April 2016, Paul Eggert wrote:
> >> For this I suggest the following heuristic. When inferring a
> >> format that would apply to two or more lines of output, try
> >> formatting the first
On 04/08/2016 01:51 PM, Ruediger Meier wrote:
On Friday 08 April 2016, Paul Eggert wrote:
For this I suggest the following heuristic. When inferring a format
that would apply to two or more lines of output, try formatting the
first two lines and report an error if they are the same.
Hm, I thi
On Friday 08 April 2016, Paul Eggert wrote:
> On 04/08/2016 05:57 AM, Pádraig Brady wrote:
> > Do we want to deal with these cases spinning the cpu,
> > in further patches?
> >
> >seq 1 nan 1
>
> NaN should be an error in any of the operands.
>
> > seq 1 .001 1
>
> F
On 04/08/2016 05:57 AM, Pádraig Brady wrote:
Do we want to deal with these cases spinning the cpu,
in further patches?
seq 1 nan 1
NaN should be an error in any of the operands.
seq 1 .001 1
For this I suggest the following heuristic. When inferring a format
On 07/04/16 15:40, Bernhard Voelker wrote:
reopen 23110
thanks
On 04/07/2016 11:46 AM, Ruediger Meier wrote:
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
Ah, okay: as there's prio
reopen 23110
thanks
On 04/07/2016 11:46 AM, Ruediger Meier wrote:
> 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
Ah, okay: as there's prior art in the BSDs [0], the attache
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
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
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.
>
Should not an increment of zero be flagged as an error, and not ignored?
Regards
Leslie
Mr. Leslie Satenstein
Montréal Québec, Canada
From: Bernhard Voelker
To: Маренков Евгений ; 23...@debbugs.gnu.org
Sent: Thursday, March 24, 2016 1:44 PM
Subject: bug#23110: seq apparent bug
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 y
Dear all,
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 ...
Best regards
Evgeny
17 matches
Mail list logo
