[Toybox] [PATCH] Fix various seq bugs.

[Rob Landley]

On 09/08/2017 06:10 PM, Rob Landley wrote:
> On 05/23/2017 02:18 AM, Josh Gao wrote:
>> On Mon, May 22, 2017 at 11:54 PM, Rob Landley <rob at landley.net
>> <mailto:rob at landley.net>> wrote:
>>
>>     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?
>>
>>
>> The surprising behavior that I ran into was this:
>>
>>     $ seq 1000000 1000001
>>     1e+06
>>     1e+06
> 
> Ok, digging back down to this, that was the only issue you hit? It
> should _not_ spontaneously produce engineering notation output? (Agreed,
> of course...)
> 
> Because you did other stuff while you were there:
> 
> 1) You changed tests/seq.test to make sure we reproduce the bug where
> seq acts like yes, counting by zero. Is there a use case for this bug?
> (Yes exists, output of seq was previously guaranteed to terminate... I
> see busybox reproduces the ubuntu behavior but that's their default
> position in the absence of a spec, I'm trying to figure out what's the
> right thing to do...)
> 
> 2) You have code to checking and make sure "1.234e06" maintains the same
> number of digits of precision. Is there something that cares about that?
> Your test is 1.0e0, which is the same with and without the e0?
> 
> (I sometimes use added tests as guidance for "use cases you care about",
> and I'm not really getting it from these...)

Also, this test:

  FAIL: seq precision last
  echo -ne '' | seq -s, 1.0 2.0 4.00
  --- expected	2017-09-09 19:11:23.901639181 -0500
  +++ actual	2017-09-09 19:11:23.909639181 -0500
  @@ -1 +1 @@
  -1.0,3.0
  +1.00,3.00

Why do the first two affect the requested precision but the third doesn't?

Rob