closed std fd rust issue

[anastygnome]

@tertsdiepraam I have opened an issue with the std guys on the closed stdin/out/err issue here
rust-lang/rust#108139

[tertsdiepraam]

Ah, that's related to this right? #2873

Have you found any previous discussion on this in the Rust repo?

Edit: You might want to expand that issue a bit. Give some use case for this behaviour and add some more motivation. It could also be intended behaviour and changing this is probably considered a breaking change. But yeah there should at least some way to control this behaviour.

[tertsdiepraam]

Found some previous discussion:

• Closed standard file descriptors don't generate errors anymore on Unix rust-lang/rust#88825
• Rust's stdio should not ignore EBADF error on non-windows platforms rust-lang/rust#47271

There's an excellent point made in one of these, which is that the only time I've seen this used is to specifically test that the closed descriptors are handled gracefully. So maybe not supporting this isn't that bad if it doesn't impact any actual scripts. In that case we'll have to adapt the GNU tests though. And I'm not sure that it's really not used meaningfully in practice.

[anastygnome]

Indeed, I have proposed providing a boolean or some feedback mechanism that we can access in case of need

[anastygnome]

@tertsdiepraam

So POSIX has been updated, this issue is deemed irrelevant as of the 2017 version

If the utility would be executed with file descriptor 0, 1, or 2 closed, implementations may execute the utility with the file descriptor open to an unspecified file.

If a standard utility or a conforming application is executed with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing, the environment in which the utility or application is executed shall be deemed non-conforming, and consequently the utility or application might not behave as described in this standard.

Quote from the issue

[tertsdiepraam]

That's very interesting! It kind of begs the question what we should do if POSIX and GNU disagree. In this case it's probably fine to follow POSIX, but there are more disagreements that we might need to look into. Thanks for the update!