If there is a [:lower:] or [:upper:] in set2, then there must be a [:lower:] or [:upper:] at the
same logical position in set1
So
tr -t [:upper:] [:lower:] works
tr -t 1[:upper:] [:lower:] doesnt
We have 3 different kinds of input:
* "algo (filename) = checksum"
example: `BLAKE2 (a) = bedfbb90d858c2d67b7ee8f7523be3d3b54004ef9e4f02f2ad79a1d05bfdfe49b81e3c92ebf99b504102b6bf003fa342587f5b3124c205f55204e8c4b4ce7d7c`
* "checksum filename"
example: `60b725f10c9c85c70d97880dfe8191b3 a`
* "checksum filename"
example: `60b725f10c9c85c70d97880dfe8191b3 a`
These algo/regexp are tricky as files can be called "a, " b", " ", or "*c".
We look at the first time to analyze the kind of input and reuse the same regexp then.
Summary of the change:
* Move the common code into checksum
* Create a structure HashAlgorithm to handle the algorithm (instead of the 3 variables)
* Use the same function for cksum & hashsum for --check (perform_checksum_validation)
* Use the same for function for the hash generation (digest_reader)
* Add unit tests
* Add integration tests
* Fix some incorrect tests
* env: adds --ignore-signal
This commit implement #6164.
* env: handle STOP signal and fix styling issue
* env: fix encoded bytes
* env: adds SAFETY comment and handle special signals in ignore_signal
* env: fix parsing to have compatible behaviour
* env: remove derive from Options
* env: changed safety comment, handle duplications after parsing and non-unix cfg
* env: adds tests for ignore-signal parsing and invalid and special signals
* env: change signal values to be non-constant
* env: adds testing for signal ignoring
* env: styling and remove unix specific derive
* test_env: add SIGSTOP to cspell workspace wordlist
* env: makes signal handling unix specific
* env: make ignore-signal function invocation unix specific
* test_env: make signal vector use slices ref instead of vec (linter)
* env: makes ignore-signal in options unix specific
* test_env: add unix specific import
* Fixed unwrap being called on dereferenced dangling symlink
* Added test
* Switched to regex matching in test
* Remove unnecessary mkdir call
* Modified documentation of the test and added assertion of the colors
* Fixed a typo
The test_cp and test_mv have xattr related tests. They should
be disabled on OpenBSD after commit 19d42c0339 disabled the
compare_xattrs function on OpenBSD.
Fixes#6348
The test_compare_xattrs test fails on OpenBSD because OpenBSD does
not support xattrs. Disabling this function and its test for
target_os = openbsd resolves the issue.
Fixes#6348
An additional issue was found while reviewing #6340, check [this thread][1]. A summary is:
- `tr` ignores the `-t`/`--truncate-set1` flag when not translating
- Not translating is defined as `-d` was passed, or one set was passed.
[1]: https://github.com/uutils/coreutils/pull/6340#discussion_r1590007053
Fixes#6163 and adds a test to verify that a regression is not caused.
Instead of inverting the conditions to check (e.g. delete characters **not** present in set1) invert
set1 when passed the complement flag (`-c`, `-C`, `--complement`). This is done by calculating set1
then "inverting" it by subtracting from the "full" (universe) set (0..=u8::MAX).
This fixes issue 6163 because it was caused by a combination of the `-c` and `-t` flag. `-c` is the
abovementioned complement flag and `-t`/`--truncate-set1` truncates set1 to the length of set2. What
happened in issue 6163 is that `set1={b'Y'}` and `set2={b'Z'}`, when truncated set1 stays the same
and we proceed. The problem is GNU utils does not consider set1 to be `{b'Y'}`, but the complement
of `{b'Y'}`, that is `U \ {b'Y'}={0, 1, ..., b'X', b'Z', ...}`, thus it is truncated to `{0}`.
We can verify this by doing: `printf '\0' | tr -c -t Y Z`, which prints `Z` to stdout as expected.
Additionally, by calculating the complement of set1 we no longer need to consider the complement
flag when doing the translate operation, this allows us to delete a lot of code.
These are non-sensical to combine, and didn't work reasonably anyway.
Also, passwd-formatting is our own extension, so there is no need for
compatibility anyway.
When printing the `du -h` output GNU coreutils does autoscale
the size, e.g.
```
$ truncate -s12M a
$ truncate -s8500 b
$ truncate -s133456345 c
$ truncate -s56990456345 d
$ du -h --apparent-size a b c d
12M a
8,4K b
128M c
54G d
```
Align our version to do the same by sharing the code with `ls`.
Closes: #6159
