It's not totally clear why they sometimes work, sometimes fail,
but it does appear that running `stat` on `/dev/stdin` is perhaps
not the most reliable approach.
A likely more solid approach is described in #7583.
Update sum to properly propagate errors from file-reads,
including implementing a retry on ErrorKind::Interrupted.
Also switch to using writeln! rather than println! to prevent
crashes if stdout is directed to /dev/full
* Fixes#7558 Added check to only insert addition double hyphen if at start of arguments to correctly prepend addition hyphens for clap as well as additional test case
* additional comment
* fixes issue where flags precedes "--" as arguments
All the other tests directly called format_float_* functions,
bypassing the additional logic in `fmt` (negative numbers, padding,
etc.).
This also tests the `parse` function in `mod.rs`, which calls back
into `try_from_spec` here. This also makes it easier to test a lot
of different format combinations without having to do end-to-end
tests in `test_printf.rs`.
Also add broken tests for the issues in #7509 and #7510.
chcon/runcon rely on the selinux crate, that is empty on
non-Linux platforms.
This doesn't matter for normal builds that use the default features
for the platform (explicitly trying to build them will fail though).
This is a problem when using `cargo test --workspace` though,
as that tries to build all packages, including uu_chcon/uu_runcon.
Just prevent compilation of these source files when target_os != linux.
Numeric sort can be relatively slow on inputs that are wholly or
mostly numbers. This is more clear when comparing with the speed of
GeneralNumeric.
This change parses whole lines as f64 and stores that info in
`LineData`. This is faster than doing the parsing two lines at
a time in `compare_by()`.
# Benchmarks
`shuf -i 1-1000000 -n 1000000 > /tmp/shuffled.txt`
% hyperfine --warmup 3 \
'/tmp/gnu-sort -n /tmp/shuffled.txt'
'/tmp/before_coreutils sort -n /tmp/shuffled.txt'
'/tmp/after_coreutils sort -n /tmp/shuffled.txt'
Benchmark 1: /tmp/gnu-sort -n /tmp/shuffled.txt
Time (mean ± σ): 198.2 ms ± 5.8 ms [User: 884.6 ms, System: 22.0 ms]
Range (min … max): 187.3 ms … 207.4 ms 15 runs
Benchmark 2: /tmp/before_coreutils sort -n /tmp/shuffled.txt
Time (mean ± σ): 361.3 ms ± 8.7 ms [User: 1898.7 ms, System: 18.9 ms]
Range (min … max): 350.4 ms … 375.3 ms 10 runs
Benchmark 3: /tmp/after_coreutils sort -n /tmp/shuffled.txt
Time (mean ± σ): 175.1 ms ± 6.7 ms [User: 536.8 ms, System: 21.6 ms]
Range (min … max): 169.3 ms … 197.0 ms 16 runs
Summary
/tmp/after_coreutils sort -n /tmp/shuffled.txt ran
1.13 ± 0.05 times faster than /tmp/gnu-sort -n /tmp/shuffled.txt
2.06 ± 0.09 times faster than /tmp/before_coreutils sort -n /tmp/shuffled.txt
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
Fixes issue #7472.
Update to head app when printing all-but-last-n-lines of a file.
Code now checks if the last line of the input file is missing a terminating
newline character, and if so prints an extra line.
This aligns with GNU-head behavior.
Also improved performance of this usecase by using an optimized iterator
(memchr-iter) for searching through the input file.
I found the logic a little difficult to understand, and the
comment probably doesn't match what `-N` is supposed to do?
Intead, let's just manually set mtime and atime.
Hopefully this helps clear up Android flakiness in #7570. Or at
least understand better what is going on.
