[Toybox] [PATCH] Fix various seq bugs.

[Rob Landley]

On 05/22/2017 12:49 PM, enh wrote:
> ping?

Sigh. I had a message half-composed when my netbook crashed last week,
noting things like how this:

> Match GNU/busybox behavior with 0 increment. (An existing test was
> failing on the host because of this.)

Is unfixing a bug I fixed. I explicitly made it not do that because if
you want "yes" it exists, and a script had a hang due to accidental
infinite output from seq with a zero increment.

Let's see, what's this precision thing...

  $ seq 1.234e3 9999 | tail -n 3
  9997.000
  9998.000
  9999.000

That's nice. You want to reproduce that exactly? Yes, there's code for it...

This is another patch adding a 20 line function to do something dubious.
I added -f way back when so you could micromanage this if you cared,
there's no posix spec on it, and the man page doesn't mention this, I
pulled up the old Red Hat 9 image I left on
https://busybox.net/downloads/qemu/ way back in the dawn of time, and:

  $ seq 1 2.000 6
  1
  3
  5

So this precision padding business was not an original feature, and got
added at some point. (Knoppix 6.7 from 2011 has it so it's not exactly
_recent_, but still.)

Did this actually confuse somebody?

     to 1. Two arguments are used as first and last. Arguments can be
-    negative or floating point.
+    positive/negative and integer/floating point.

The arguments _aren't_ integer, doubles have 53 bits of precision. Feed
it a 64 bit number it's not going to work, the help text might as well
say it's a double...

What's the use case for this code? Did they notice a difference from gnu
and say "any difference is a bug", or was somebody actually trying to do
something that broke?

Sigh, lemme see what I can do with this patch...

Rob