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 .0000000000000000000000000000001 1
>
> 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 think printing identical lines is a valid use case:
$ seq -f "%0.1f" 0 0.02 0.1
0.0
0.0
0.0
0.1
0.1
0.1
> That would
> catch the seeming infinite loop (and at any rate, inadequate output)
> in this example.
I would check it before the loop like this
if ((first + inc) == first)
/* exit error */
Note this still wouldn't catch this one
seq 0 .0000000000000000000000000000001 1
But this would run millions of years anyway even if the increment would
work and moreover maybe the user _wants_ an effective endless (non
trivial) sequence like this
seq 0 1 999999999999999999999999999999
> > As an aside, I see FreeBSD requires the STEP to be in the right
> > direction when FIRST != LAST, or it will also exit with error.
> > GNU will just output nothing in that case.
>
> Outputting nothing sounds better. 'seq 1 0' is like 'for (i = 1; i <=
> 0; i++) ...'
I also guess that some people may have used this coreutils feature
already in scripts:
# do nothing if inc = -1
for i in `seq 0 $inc 100`;do something; done
cu,
Rudi
