Unify execute_command across platforms

[reima]

Fixes #178 by providing an empty stdin, which leads to the command not blocking on input.

To achieve this, I removed the #[cfg(all(unix))] implementation of execute_command in favor of the simpler #[cfg(not(unix))] implementation (which is now used unconditionally). This implementation uses Command::output, which by default captures stdout and stderr and provides an empty stdin.

Incidentally, this also fixes an (unreported) bug in the removed execute_command implementation: when the command output grew larger than the size of a pipe, a deadlock occured:

• The command was blocked on writing to the filled pipe.
• fd was blocked on waiting for the command to finish.

I'm not entirely sure why we even had the removed execute_command to begin with, as using the Command's built-in output capture features seem to work just fine on Unix configurations.

[jakwings]

@mmstick /cc

I also tried using Command::output, but it doen't capture anything on my mac. So, that separate implementation is a fix for unixes, not RedoxOS.

[jakwings]

Ah, sorry, I said it wrong. It does capture output but there seemed to be something wrong with stdin. I don't remember.

[mmstick]

Is STDIN_FILENO being closed in the child before executing the command?

[jakwings]

Yes, the stdin is closed. (checked with libc::isatty in .before_exec())

But the doc said Command::output: By default, stdin, stdout and stderr are captured (and used to provide the resulting output).

[reima]

@mmstick Yes. Technically std::process::Command::output excutes the command first with the command's stdin set to /dev/null (null: on Redox, NUL on Windows), and then closes the command's stdin in std::process::Child::wait_with_output.

[sharkdp]

Thank you very much!

[jakwings]

This issue confirm the behavior of Command::output: rust-lang/rust#46220