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>
* kill: print --table as vertical
* kill: remove signal padding on --table
* kill: skip exit signal in --table
* kill: replace "skip" with "filter"
---------
Co-authored-by: Daniel Hofstetter <daniel.hofstetter@42dh.com>
* kill: return 1 and gnu style stderr in case of no pid
closes#6221
* Update src/uu/kill/src/kill.rs
Co-authored-by: Ben Wiederhake <BenWiederhake.GitHub@gmx.de>
---------
Co-authored-by: Ben Wiederhake <BenWiederhake.GitHub@gmx.de>
If the first four decimal digits are zero, GNU dd elides them altogether.
Therefore, this test just contained an overly-strict regex.
See also ede944e1f8.
* date: fix `date -f dates.txt is failing`
This commit is a trivial followup for:
https://github.com/uutils/coreutils/pull/4917
and
https://github.com/uutils/parse_datetime/pull/12
The functionality to parse the datetime was moved into the parse_datetime
crate and the only (tiny) piece left is to call it from `date`.
It also adds the test-case from the original issue. I did not include
the two tests from PR#4917 because they appear to work even without
this change. I am happy to include them of course if prefered.
Closes: #4657
Thanks to Ben Schofield
* tests: tweak changes to test_date.rs to be more idiomatic
Co-authored-by: Sylvestre Ledru <sylvestre@debian.org>
---------
Co-authored-by: Sylvestre Ledru <sylvestre@debian.org>
When building coreutils I got the following deprecation warning:
```
warning: use of deprecated method `chrono::NaiveDateTime::timestamp_subsec_nanos`: use `.and_utc().timestamp_subsec_nanos()` instead
--> tests/by-util/test_touch.rs:37:59
|
37 | ..._utc().timestamp(), tm.timestamp_subsec_nanos())
| ^^^^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(deprecated)]` on by default
warning: `coreutils` (test "tests") generated 1 warning
```
This commit fixes it.
