Nix sh command dependency

[josh]

I was experimenting with some of the nice Pimalaya CLI tools via Nix and noticed a few cases where running in an isolated environment (without PATH set) caused subcommands to fail.

core/process/src/command.rs

Line 194 in 847c304

let (shell, arg) = if windows { ("cmd", "/C") } else { ("sh", "-c") };

Here it's assumed sh is provided in the environment PATH.

I think this assumption could be reasonable, and the usual fix at the nix package level is to create a wrapper ensuring pkgs.bash is set on the PATH.

An alternative approach might be to make this dependency explicitly configurable at compile time, avoiding the need for additional wrappers. I'm not very familiar with Rust, but is there a compile-time flag convention for specifying runtime tool locations, such that the bash path could be baked into the binary?

Just curious what you think about this? Thanks!

[soywod]

Very good question. To be honest I am not that fan of this wrapper anymore. It already shown its limit many times. It's been a while I think about just getting rid of it for the following reasons:

1. No more issue with sh not found
2. No more OS condition
3. People can still decide to wrap their own command, manually

Let's keep this issue open for the purpose of removing it. Thank you for finally initiating this refactor!

[josh]

Oh, right, I didn't even consider dropping the sh subshell all together. I assume that's what you mean. Much simpler. I think as along as there's some basic parsing for additional arguments and handling quoting nuances, that'd be good enough for most people. And if you really want to have pipes and stuff in that expression, you can call sh -c yourself.