Use an infinite sequence in `test_broken_pipe_still_exits_success` instead of
finite range (1-5) to guarantee a burst of output immediately after spawn,
preventing the process from finishing before stdout closure and avoiding
missed broken pipe errors.
* fix(seq): handle BrokenPipe like GNU
* test: add Unix-specific test for seq command broken pipe handling
- Ensures seq exits gracefully with code 0 and reports "Broken pipe" error on stderr when stdout pipe is prematurely closed
- Validates correct behavior for common scenario where output is piped to commands like head that terminate early
* refactor(test): translate Japanese comment to English in test_seq.rs
- Updated a comment in the test for broken pipe behavior to use English instead of Japanese, enhancing readability for non-Japanese speakers and aligning with project standards. No functional changes to the test logic.
A lot of custom logic, we basically do arithmetic on character
arrays, but this comes at with huge performance gains.
Unlike coreutils `seq`, we do this for all positive increments
(because why not), and we do not fall back to slow path if
the last parameter is in scientific notation.
Also, add some tests for empty separator, as that may catch
some corner cases.
GNU `seq` doesn't support such large positive exponents anyway,
and we are limited by i64 range, so increase the exponent value
to make sure we fully overflow that range.
Also, add a test to check that a very, very, small number is
treated as 0 (that's also undefined behaviour, but it does
make sense in a way).
Some of these tests are not completely defined behavior, but
in many cases they make sense (or at least one can find some
consistent logic to it).
However, there are 2 edge cases that are more dubious IMHO.
One of them has been reported on list a while back, and I
just reported another.
Tests for both `seq` and `yes` run a command that never terminates,
and check the beggining of their output in stdout, move the copied
parts of the wrapper function to common/util.
We still need to use slightly different logic to parse exit value
as `seq` returns success if stdout gets closed, while `yes` fails.
* seq:enable parsing of hexadecimal floats
Turn on the float parser. Now it's possible to use hexadecimal floats as
parameters. For example,
cargo run -- 0x1p-1 3
0.5
1.5
2.5
Issue #6935
---------
Co-authored-by: Daniel Hofstetter <daniel.hofstetter@42dh.com>
Co-authored-by: Sylvestre Ledru <sylvestre@debian.org>
Improve the error message produced by `seq` when given invalid format
specifiers for the `-f` option. Before this commit:
$ seq -f "%" 1
seq: %: invalid conversion specification
$ seq -f "%g%" 1
seq: %: invalid conversion specification
After this commit:
$ seq -f "%" 1
seq: format '%' ends in %
$ seq -f "%g%" 1
seq: format '%g%' has too many % directives
This matches the behavior of GNU `seq`.
Chris DrydenandGitHub
mattsu
mattsuandGitHub
Daniel Hofstetter
Dorian Peron
Luv-RayandGitHub
Nicolas Boichat
Sylvestre Ledru
Alexander Shirokov
Jeffrey Finkelstein