This commit replaces generic Results with UResults in some key
functions in numfmt. As a result of this, we can provide different
exit codes for different errors, which resolves ~70 failing test
cases in the GNU numfmt.pl test suite.
Fix two issues with the filename creation algorithm. First, this
corrects the behavior of the `-a` option. This commit ensures a
failure occurs when the number of chunks exceeds the number of
filenames representable with the specified fixed width:
$ printf "%0.sa" {1..11} | split -d -b 1 -a 1
split: output file suffixes exhausted
Second, this corrects the behavior of the default behavior when `-a`
is not specified on the command line. Previously, it was always
settings the filenames to have length 2 suffixes. This commit corrects
the behavior to follow the algorithm implied by GNU split, where the
filename lengths grow dynamically by two characters once the number of
chunks grows sufficiently large:
$ printf "%0.sa" {1..91} | ./target/debug/coreutils split -d -b 1 \
> && ls x* | tail
x81
x82
x83
x84
x85
x86
x87
x88
x89
x9000
* print error in the correct order by flushing the stdout buffer before printing an error
* print correct GNU error codes
* correct formatting for config.inode, and for dangling links
* correct padding for Format::Long
* remove colors after the -> link symbol as this doesn't match GNU
* correct the major, minor #s for char devices, and correct padding
* improve speed for all metadata intensive ops by not allocating metadata unless in a Sort mode
* new tests, have struggled with how to deal with stderr, stdout ordering in a test though
* tried to implement UIoError, but am still having issues matching the formatting of GNU
Co-authored-by: electricboogie <32370782+electricboogie@users.noreply.github.com>
Fix a bug in which a negative decimal input would not be displayed with
the correct width in the output. Before this commit, the output was
incorrectly
$ seq -w -.1 .1 .11
-0.1
0.0
0.1
After this commit, the output is correctly
$ seq -w -.1 .1 .11
-0.1
00.0
00.1
The code was failing to take into account that the input decimal "-.1"
needs to be displayed with a leading zero, like "-0.1".
Pad infinity and negative infinity values with spaces when using the
`-w` option to `seq`. This corrects the behavior of `seq` to match that
of the GNU version:
$ seq -w 1.000 inf inf | head -n 4
1.000
inf
inf
inf
Previously, it incorrectly padded with 0s instead of spaces.
