In such cases we have to create a temporary copy of the input file to prevent
overwriting the input with the output. This only affects merge sort, because it
is the only mode where we start writing to the output before having read all inputs.
Since lines that compare equal should be sorted together, we need to first
compare the lines (taking settings into account). Only if they do not compare
equal we should compare the hashes.
Add support for
* space-separated list of tab stops, like `--tabs="2 4 6"`,
* mixed comma- and space-separated lists, like `--tabs="2,4 6"`,
* the slash specifier in the last tab stop, like `--tabs=1,/5`,
* the plus specifier in the last tab stop, like `--tabs=1,+5`.
The custom usage string does not have to include the "sort\nUsage:" part,
because this part is already printed by clap.
It prevents the following duplication:
USAGE:
sort
Usage:
sort [OPTION]... [FILE]..
Now, only the following is printed:
USAGE:
sort [OPTION]... [FILE]...
Change the behavior of `tac` when there are no line separators in the
input. Previously, it was appending an extra line separator; this commit
prevents that from happening. The input is now writted directly to
stdout.
Correct the error message produced by `tac` when trying to read from a
directory. Previously if the path 'a' referred to a directory, then
running `tac a` would produce the error message
dir: read error: Invalid argument
after this commit it produces
a: read error: Invalid argument
which matches GNU `tac`.
Add a note the licensing section, stating that references using the
Apache License are acceptable on a case-by-case basis when there is no
MIT-licensed alternative.
* Follow-up to #1994 / https://github.com/uutils/coreutils/pull/2493
* Intended to resolve issue #2086
Make all tests lock a mutex to ensure that they're run in series rather than
parallel. We must take this precaution due to the fact that all tests are run
in parallel as threads of one parent process. As all threads in a process share
e.g. environment variables, we use the Mutex to ensure they're run one after
another.
This way we can guarantee that tests that rely on environment variables to have
specific values will see these variables, too.
An alternative implementation could have used the [rusty fork][1] crate to run
all tests that need env variables in separate processes rather than threads.
However, rusty fork likely wouldn't run on all platforms that the utilities are
supposed to run on.
