exit(130) is not the same as raise(SIGINT)

[tavianator]

fd handles ^C by propagating ExitCode::KilledBySigint up to main() which does process::exit(exit_code.into()). But exit code 130 is a lie told by bash (this comment has a good explanation: rust-lang/rust#62569 (comment)).

This is observable from programs that check WIFEXITED()/WIFSIGNALED(). Here's a crude example:

$ bfs -D exec /dev/null -exec fd . / \; >/dev/null & sleep 1; pkill -INT fd; wait %1
bfs: -D exec: -exec: Executing 'fd' ... [2 arguments]
bfs: warning: Command 'fd' terminated by signal 2 (Interrupt)
$ bfs -D exec /dev/null -exec fd --color=always . / \; >/dev/null & sleep 1; pkill -INT fd; wait %1
bfs: -D exec: -exec: Executing 'fd' ... [3 arguments]
bfs: -D exec: -exec: Command 'fd' failed with status 130

The right way to pretend to die by SIGINT is something like signal(SIGINT, SIG_DFL); raise(SIGINT);.

[sharkdp]

Thank you for reporting this. I guess this should be easy to fix using sth. like nix::sys::signal::raise?

Or maybe we avoid that dependency and add some unsafe code using libc::raise directly? nix is in the dependency tree via ctrlc anyway.

[tavianator]

Yeah that's what I was thinking. Didn't get around to it yet because I'm not sure what the right behavior is on Windows. But I could at least fix it on *nix first

[tmccombs]

using raise is the right way to do it on *nix. I have no idea about windows though. Windows doesn't even use signals as I understand it.