Ctrl+C on `cargo run`
alexreg opened this issue · comments
When I Ctrl+C on cargo run and my Rust program is set up to intercept the signal, the Rustup process stops and returns control to the terminal, even though my Rust program (and indeed Cargo) may still be running. I've observed this on the latest version of Rustup.
I think it would be best for Rustup to do something similar to what cargo run does, and intercept Ctrl+C when running a program, and ignore it – instead, it should just check regularly to see if the program (cargo) has exited.
Note: this is confirmed not to be a cargo issue, as per rust-lang/cargo#3281.
What is the status of the issue?
What is the status of the issue?
Is it still relevant?
I can work on it if it is relevant.
I am working on it.
Some rationale here: #972 (comment)
This still happens on Windows.
Steps to reproduce
- Create the following program:
// [dependencies] // ctrlc = "*" fn main() { ctrlc::set_handler(move || { println!("Ctrl-C received, but I'm not exiting."); }); loop {} }
cargo run(where cargo is rustup)- Press
Ctrl-C.
Expected result
The program should print Ctrl-C received, but I'm not exiting. and continue running.
Actual result
The program terminates.
Version info
> rustup --version
rustup 1.18.3 (435397f48 2019-05-22)
I tried it without (C:\Users\username\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\bin\cargo.exe run). It works as expected.
Cargo itself used to have this problem before (rust-lang/cargo#4575), but it was solved with this workaround: rust-lang/cargo#6004.
@alexcrichton Do you have any idea of the complexity of resolving this for rustup?
The Cargo solution looked like rust-lang/cargo#6004 for Windows, so based on that I'd guess it'd have a relatively small impact?
Assuming #2014 builds OK, could @Vlad-Shcherbina or @alexreg please go to the PR, go through to the appveyor build, find the artifact, download a test copy of rustup install it and give it a go?
My apologies, it looks like the artifacts don't get collected, so you'll need to build a copy locally.
In the scenario I described, #2014 appears to work as expected.