Ctrl+C on cargo run

[alexreg]

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.

[KalitaAlexey]

What is the status of the issue?

[KalitaAlexey]

What is the status of the issue?
Is it still relevant?
I can work on it if it is relevant.

[alexreg]

Yep, very much relevant still, I believe.

…

On 26 Feb 2017, at 07:36, Alexey ***@***.***> wrote: What is the status of the issue? Is it still relevant? I can work on it if it is relevant. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#806 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEF3IAF4pILJTaMK_3mRdpQJeQynIjjks5rgSuNgaJpZM4Kv1e9>.

[KalitaAlexey]

I am working on it.

[brson]

I'd like to solve this and #845 without giving up fork/exec. A strategy along the lines @alexreg describes in the op seems workable.

[brson]

Some rationale here: #972 (comment)

[Vlad-Shcherbina]

This still happens on Windows.

Steps to reproduce

1. Create the following program:

   // [dependencies]
   // ctrlc = "*"
   fn main() {
       ctrlc::set_handler(move || {
           println!("Ctrl-C received, but I'm not exiting.");
       });
       loop {}
   }

2. cargo run (where cargo is rustup)
3. 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.

[kinnison]

@alexcrichton Do you have any idea of the complexity of resolving this for rustup?

[alexcrichton]

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?

[kinnison]

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?

[kinnison]

My apologies, it looks like the artifacts don't get collected, so you'll need to build a copy locally.

[Vlad-Shcherbina]

In the scenario I described, #2014 appears to work as expected.