[MacPorts] #72225: system "cargo <opts>" leads to `sh` zombie when `cargo` fails or is interrupted

[MacPorts]

#72225: system "cargo <opts>" leads to `sh` zombie when `cargo` fails or is
interrupted
--------------------+--------------------
 Reporter:  RJVB    |      Owner:  (none)
     Type:  defect  |     Status:  new
 Priority:  Normal  |  Milestone:
Component:  base    |    Version:
 Keywords:          |       Port:
--------------------+--------------------
 I already raised this via a rather incredulous message on macports-dev but
 I now have some confirmation that I'm not the only one seeing the issue:

 https://github.com/rust-lang/cargo/issues/14929

 Invoking `cargo` as `build.cmd` or in a direct command executed with
 base::system can (and often does) lead to a zombie `sh` process if `cargo`
 exits with an error or crashes or even if it's interrupted. This happens
 both on Mac and in my MacPorts port for Linux (where `sh` is actually
 `dash`).

 I have no idea how this can happen but it is very annoying because you
 have to kill the `port` command with a kill -9 and that means the logfile
 isn't flushed so there is usually no information about what happened. I
 assume it may have to do with the `cargo` command setting its own signal
 handlers or maybe trying to alter the process group.

 I do notice that `system -W /path "foo"` is expanded to `sh -c "cd /path
 && foo"` and this seems a bit more complex than needed. Since base::system
 uses `fork()` + `execve()`, why not do a `chdir(2)`  in the child process
 *before* rather than doing it *in* `sh`?

-- 
Ticket URL: <https://trac.macports.org/ticket/72225>
MacPorts <https://www.macports.org/>
Ports system for macOS