* Make fperm hold 6 digit octal permission. Set it to 4 digits when displaying
* Add test
* Make every permission 4 octal digits
* Change test name to be more suggestive
* chmod: merge two args in test
---------
Co-authored-by: Daniel Hofstetter <daniel.hofstetter@42dh.com>
Note in particular that `args_override_self` would *NOT* work here,
since it would in all cases cause `options::NAME` to override itself,
or interfere with `trailing_var_arg`.
The testcase tries to write to the stdin pipe while the process under
test is simultaneously exiting with an error code. Naturally, this is a
race, and we should ignore any stdin write errors. However, adding this
feature to the list makes it even more unreadable, and adds no real
value, so let's skip the input data entirely.
This was a GNU behavior bug:
```console
$ LC_ALL=C shuf -er
shuf: no lines to repeat
[$? = 1]
$ cargo run shuf -er # old, bad (unexpected success)
$ cargo run shuf -er # new
shuf: no lines to repeat
[$? = 1]
```
If the first four decimal digits are zero, GNU dd elides them altogether.
Here's an execution on my PC:
```console
$ for i in $(seq 20000); do LC_ALL=C gnu_dd if=/dev/null of=/dev/null \
2>&1; done | grep copied | grep -E ' [0-9]e'
0 bytes copied, 1e-05 s, 0 B/s
0 bytes copied, 9e-06 s, 0.0 kB/s
```
Our implementation conforms to this, resulting in the following CI flake:
```
---- test_dd::test_final_stats_unspec stdout ----
run: D:\a\coreutils\coreutils\target\x86_64-pc-windows-gnu\debug\coreutils.exe dd
thread 'test_dd::test_final_stats_unspec' panicked at 'Stderr does not match regex:
0+0 records in
0+0 records out
0 bytes copied, 8e-05 s, 0.0 B/s
', tests\by-util\test_dd.rs:280:10
stack backtrace:
0: rust_begin_unwind
at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library\std\src/panicking.rs:578:5
```
Of course, this is just an overly strict regex in the test. This was a
one-in-tenthousand flaky test.
See also 9995c637aa.
There is a race condition between the writing thread and the command.
It is easily possible that on the developer's machine, the writing
thread is always faster, filling the kernel's buffer of the stdin pipe,
thus succeeding the write. It is also easily possible that on the busy
CI machines, the child command runs first for whatever reason, and exits
early, thus killing the pipe, which causes the later write to fail. This
results in a flaky test. Let's prevent flaky tests.
The comment was introduced in commit 8320b1ec5f,
the test was introduced in commit c1f518e586
claiming to be about "failing GNU head tests".
However, a simple check reveals no such difference:
```console
$ echo -n a | hd
00000000 61 |a|
00000001
$ echo -n a | head | hd # GNU head
00000000 61 |a|
00000001
$ echo -n a | cargo run -- head | hd
00000000 61 |a|
00000001
$ echo -n a | busybox head | hd
00000000 61 |a|
00000001
$
```
Looking at the GNU tests directly, it seems that there is a similar, but different test.
