dd: should return 1 on closed stderr but returns 0

[jfinkels]

GNU dd v9.4.113-c01ee:

$ : | dd 2>&-; echo $?
1

uutils dd:

$ : | ./target/debug/dd 2>&-; echo $?
0

This test case appears in GNU test suite file tests/dd/stderr.sh.

[tertsdiepraam]

This is super hard to fix if I recall correctly, because Rust reopens stdout and stderr before we even get to main. This is one of those cases where I would just say that we should document the difference and ignore the test.

[jfinkels]

Here is an earlier issue where we investigated closed stdin: #2873

[jfinkels]

Related to #3744. There is a GNU test file tests/misc/close-stdout.sh that addresses this behavior for several programs.

[ChrisDryden]

Trying to link all of these similar root cause tickets together, but I have a proposed fix for this by using the approach of storing the state of the stdin and stdout before the runtime sanitizes it to dev/null #9664

I have been working around with seeing how it applies to this use case and all of the use cases in close-stdout.sh in this draft PR and it appears to be able to address all of the GNU tests: #9646 Theres still other functionality in utilities like fold to make the test fully pass but this should cover all of the use cases related to closed stdin and stdout

[anastygnome]

closed stdin is not compliant. I'm doubtful whether we should do this
(see this comment on stdlib) rust-lang/rust#108139 (comment)

[ChrisDryden]

I see where the argument is coming from, but I think in this case the if there's a mismatch between POSIX compliance and GNU Coreutils the goal is to match GNU Coreutils. The proposal is to do what @the8472 is describing and "adding a static initializer and recording the state of the file descriptors before main"