Sigh. I had a message half-composed when my netbook crashed last week,
Post by enh
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
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
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...