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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
