Subcommands that take their time with exit cleanup make the shell prompt weird

[golddranks]

When cargo runs a(n external) subcommand, that subcommand can set signal handlers to respond to events like the user pressing Ctrl-C (I think this is the most common case). I noticed that if the process takes some time when exiting, the shell prompt appears too early, when the subcommand hasn't exited yet. If the subcommand prints something out on exit, this makes the shell prompt act weird.

When the subcommand binary is run as standalone, this doesn't happen. I think the problem is that because according to POSIX, all the processes in the process group receive the signal, both cargo and the subcommand receive it, but cargo returns immediately whereas the subcommand takes its time. Because cargo returns, the shell prints already its prompt, but this is garbled by the subcommand that prints exit messages.

Maybe cargo could wait for the subcommand to finish before exiting?

[alexcrichton]

Cargo doesn't currently handle signals, which means that if you ctrl-c Cargo you're sending a ctrl-c to the entire process group, killing Cargo and all child processes by default. As Cargo is typically the "controlling" process then the stdout/stderr pipes are torn down once Cargo itself dies and the host shell starts cleaning up.

The "fix" here would probably be to use exec_replace when executing subcommands, whereas today we probably don't use exec

[golddranks]

I was thinking the same. Is there anything that would prevent doing this? The way I understand it, Cargo just calls the subcommand and hands over (it doesn't do any substantial "cleanup" after the subcommand finishes), so using exec shouldn't break anything?

[alexcrichton]

Yeah should be reasonable to implement, would you be interested in sending a PR for this?

[golddranks]

Sent a PR!