y.sh cargo run swallows the signal emitted by the running process

[antoyo]

For instance, if the process segfaults, ./y.sh cargo run will not emit a SIGSEGV signal while it should do that.

[GuillaumeGomez]

I don't think signals should be emitted by the parent as well (in this case, SIGSEGV tells that a memory access was wrong, which is only the case of the child, not the parent). We should display which signal ended the process though if any.

[antoyo]

cargo does it, so I believe we should do the same.

[bjorn3]

On Unix you could exec cargo instead of spawning it as subprocess. That is what cargo-clif and rustc-clif do.

[antoyo]

In my sync PR, it seems like this is still happening, re-opening just in case.

[antoyo]

So, it looks like we return 1 instead of raising the signal of the child process.

[GuillaumeGomez]

Do we want to re-raise the signal though?

[antoyo]

Yes. I'd like the same behavior as cargo for the y.sh cargo command.