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
* seq: add the unit test even if they are failing for now
* improve test
Co-authored-by: Daniel Hofstetter <daniel.hofstetter@42dh.com>
---------
Co-authored-by: Daniel Hofstetter <daniel.hofstetter@42dh.com>
