[Alacritty/Windows] ctrl-c a process launched in nushell kills the terminal

[midnightexigent]

Describe the bug

Interestingly, when nu is spawned from a parent shell (eg. powershell), the problem doesn't occur

How to reproduce

1. in alacritty.yml, set the shell to nu
2. open an alacritty window
3. start any process (eg. sleep 10sec)
4. ctrl-c to interrupt it

Expected behavior

I expect the process to stop without killing the parent terminal

Screenshots

No response

Configuration

version | pivot
────┬────────────────────┬────────────────────────────────────────────────────────────────────────────────────
 #  │      Column0       │                                      Column1
────┼────────────────────┼────────────────────────────────────────────────────────────────────────────────────
  0 │ version            │ 0.35.0
  1 │ short_commit       │ bc682066
  2 │ commit_hash        │ bc682066d8eb756727c38d98ae58a34dd9cb3b38
  3 │ commit_date        │ 2021-08-03 08:01:09
  4 │ build_os           │ windows-x86_64
  5 │ rust_version       │ rustc 1.54.0 (a178d0322 2021-07-26)
  6 │ rust_channel       │ stable-x86_64-pc-windows-msvc (default)
  7 │ cargo_version      │ cargo 1.54.0 (5ae8d74b3 2021-06-22)
  8 │ pkg_version        │ 0.35.0
  9 │ build_time         │ 2021-08-03 08:46:53
 10 │ build_rust_channel │ release
 11 │ features           │ clipboard-cli, ctrlc, dataframe, default, rustyline, term, trash, uuid, which, zip
 12 │ installed_plugins  │
────┴────────────────────┴────────────────────────────────────────────────────────────────────────────────────

Additional context

No response

[fdncred]

Is ctrlc_exit set to false in your config.toml? If not, try it to see if it changes the behavior. You'll have to quit out of nushell and restart to get the config change to apply. The config file is at $nu.config-path. I'm not sure right now what our defaults are. LOL.

[midnightexigent]

it didn't change the behavior

~
❯ config
───┬────────────┬─────────────────
 # │ ctrlc_exit │     prompt
───┼────────────┼─────────────────
 0 │ false      │ starship prompt
───┴────────────┴─────────────────

[fdncred]

I'm not sure then. We've had people report similar issues before but it's usually what I said with the ctrlc_ext. You might search the issues repo to see what others have found.

[midnightexigent]

This might be due to the fact that nushell doesn't create a new process group when spawning a process

There was a similar issue when using the zellij multiplexer with nushell

[hunger]

Same issue here, but with nushell 0.42.0 build with --features extra.

For me ctrlc is actually listed as a feature, but I can not spot it in config. When I do config set ctrlc_exit false that does not change anything (as does setting this to true).

To test I start gitk and leave that running and try to quit it with Ctrl-C. The shell is closed instead -- at least gitk also closes.

[fdncred]

does the same problem exist in engine-q?

[hunger]

How do I test that?

[fdncred]

you try out our new engine by compiling it and running it and then trying to reproduce the problem.

[hunger]

I narrowed down the problem a bit: It happens only when using nu as a shell in a systemd-nspawn container directly! I use that a lot and hardly ever run a shell in my main system, so I had not notices that yet, sorry!

machinectl shell /path/to/machine/dir /usr/bin/nu has the Ctrl-C problem. Doing machinectl shell /path/to/machine/dir /usr/bin/bash and then starting nu in bash works fine.

engine-q has exactly the same behavior as nu in this regard: It works fine when any other shell has been launched in the nspawn container before but quits when Ctrl-C is sent to it and it is the first shell in that container.

Both engine-q and nu run fine in a kitty terminal window as long as systemd-nspawn is not involved.

[midnightexigent]

This is no longer happening in 0.43.0

❯ version | pivot
────┬────────────────────┬─────────────────────────────────────────────────────────────────────────────────────
 #  │      Column0       │                                       Column1
────┼────────────────────┼─────────────────────────────────────────────────────────────────────────────────────
  0 │ version            │ 0.43.0
  1 │ short_commit       │ 4e8e0386
  2 │ commit_hash        │ 4e8e03867c87307d536369a20dbe81491666ee51
  3 │ commit_date        │ 2022-01-18 17:51:21 +00:00
  4 │ build_os           │ windows-x86_64
  5 │ rust_version       │ rustc 1.58.0 (02072b482 2022-01-11)
  6 │ rust_channel       │ stable-x86_64-pc-windows-msvc
  7 │ cargo_version      │ cargo 1.58.0 (7f08ace4f 2021-11-24)
  8 │ pkg_version        │ 0.43.0
  9 │ build_time         │ 2022-01-18 18:21:27 +00:00
 10 │ build_rust_channel │ release
 11 │ features           │ ctrlc, dataframe, default, rustyline, term, trash, uuid, which, zip
 12 │ installed_plugins  │ binaryview, chart bar, chart line, fetch, from bson, from sqlite, inc, match, post,
    │                    │ ps, query json, s3, selector, start, sys, textview, to bson, to sqlite, tree, xpath
────┴────────────────────┴─────────────────────────────────────────────────────────────────────────────────────

[hunger]

No change for me in a systemd-nspawn container using

───┬────────────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 # │      Column0       │                                                                                 Column1                                                                                 
───┼────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 0 │ version            │ 0.43.0                                                                                                                                                                  
 1 │ build_os           │ linux-x86_64                                                                                                                                                            
 2 │ rust_version       │ rustc 1.60.0-nightly (9ad5d82f8 2022-01-18)                                                                                                                             
 3 │ rust_channel       │ nightly-x86_64-unknown-linux-gnu                                                                                                                                        
 4 │ cargo_version      │ cargo 1.60.0-nightly (358e79fe5 2022-01-04)                                                                                                                             
 5 │ pkg_version        │ 0.43.0                                                                                                                                                                  
 6 │ build_time         │ 2022-01-19 10:32:04 +01:00                                                                                                                                              
 7 │ build_rust_channel │ release                                                                                                                                                                 
 8 │ features           │ ctrlc, dataframe, default, rustyline, term, trash, uuid, which, zip                                                                                                     
 9 │ installed_plugins  │ binaryview, chart bar, chart line, fetch, from bson, from sqlite, inc, match, post, ps, query json, s3, selector, start, sys, textview, to bson, to sqlite, tree, xpath 
───┴────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

I still see this problem:-/

[hustcer]

@hunger Can you try again on the latest main branch? Seems fine for me.

[hunger]

I stil, have that issue with nu at version 44.

I run nu in a systemd-nspawn container, start gitk and hit Ctrl-C. Nu quits, the container quits and I am in the shell I ran systemd-nspawn in.

Note stat I am on Linux, not windows.

[fdncred]

what about in version 0.59.1? I don't think we're going to fix 0.44 since we're so close to releasing 0.60.

[hustcer]

latest main will be nu 0.59.1

[hunger]

Sorry for that, I just did cargo install --force nuand that installs version 0.44. I'll check the website for instructions on how to get a newer version

[fdncred]

no worries - the newest version is in beta. You can read about it here https://www.nushell.sh/blog/2022-03-01-nushell_0_59.html. You can also compile it from the latest main branch of our repo.

[hunger]

I grabbed the binaries from the blog post you linked to: Exactly the same behavior:-/

Connected to machine barfoo. Press ^] three times within 1s to exit session.
/home/dev〉version | transpose                                                                                                                                                                                            03/10/2022 03:35:50 PM
╭────┬────────────────────┬──────────────────────────────────────────╮
│ #  │      column0       │                 column1                  │
├────┼────────────────────┼──────────────────────────────────────────┤
│  0 │ version            │ 0.59.0                                   │
│  1 │ branch             │ main                                     │
│  2 │ short_commit       │ 42f1874a                                 │
│  3 │ commit_hash        │ 42f1874a3aae2e3bc3c669cb0aac0132a586ea24 │
│  4 │ commit_date        │ 2022-03-01 13:05:29 +00:00               │
│  5 │ build_os           │ linux-x86_64                             │
│  6 │ rust_version       │ rustc 1.59.0 (9d1b2106e 2022-02-23)      │
│  7 │ rust_channel       │ stable-x86_64-unknown-linux-gnu          │
│  8 │ cargo_version      │ cargo 1.59.0 (49d8809dc 2022-02-10)      │
│  9 │ pkg_version        │ 0.59.0                                   │
│ 10 │ build_time         │ 2022-03-01 13:31:35 +00:00               │
│ 11 │ build_rust_channel │ release                                  │
│ 12 │ features           │ dataframe, default, trash, which, zip    │
│ 13 │ installed_plugins  │                                          │
╰────┴────────────────────┴──────────────────────────────────────────╯
/home/dev〉gitk                                                                                                                                                                                                           03/10/2022 03:36:00 PM
^C
Connection to machine barfoo terminated.
tobias@foobar:~ ➜ 

[fdncred]

hmmm, i can't reproduce it but i don't ssh/connect to other machines. i wonder if the ctrl-c is being passed back to the connecting app (ssh or whatever) then the host app is processing the ctrl-c. Coming from a host like powershell and then nushell the ctrl-c would be passed to powershell after nushell exits. so, it kind of makes sense to me.

[hunger]

It does not happen when I run bash inside the container and start nu in that bash shell. It behaves as espected then: Ctrl-C kills gitk and returns me into nu.

That's why I suspect (without any understanding of the problem space:-) that this might be some terminal setup issue or something: If the terminal is set up correctly (by some other shell) then it works.

[fdncred]

I have alacritty for windows v10.1 with nu.exe set as the shell and don't have any exit issues. I can hit ctrl-c a dozen times in rapid succession without exiting. It doesn't stop the propmt scripts from running, because i'm hitting ctrl-c so fast but it comes back on the next enter.

[hunger]

I have no clue about shells and terminal, but I suspect that is "just" a "set up the terminal" issue.

Windows and Linux are two very different beasts in that regard. I am not surprised that it works in windows. It also works in Linux -- provided it is started inside another shell like bash or fish, even in a container. Started in a container without bash and fish? Nope, it does not work there.

Is there anything I can do to help reproduce the issue?

[fdncred]

I don't have a way really to test this on Linux. I could try on WSL2 but I'm not sure that would be the same.

[midnightexigent]

@fdncred does nushell 0.59 create a new process group when spawning a new process ? If not, then all processes are in the same foreground group, so ctrlc sends the signal to every member of the group -- the behavior is normal

[midnightexigent]

This might be due to the fact that nushell doesn't create a new process group when spawning a process

There was a similar issue when using the zellij multiplexer with nushell

Up

[fdncred]

@fdncred does nushell 0.59 create a new process group when spawning a new process ? If not, then all processes are in the same foreground group, so ctrlc sends the signal to every member of the group -- the behavior is normal

No, I don't believe nushell creates a process group as it is starting.

[midnightexigent]

sooo I guess that's what's causing the problem.. ?

[fdncred]

I'd like to be able to reproduce the problem before saying that's the diagnosis.

[midnightexigent]

idk about reproducing it with @hunger's setup, but, you might be able to reproduce a similar behavior (unsure because I haven't checked for myself) with zellij 0.14 on linux.

More details: zellij-org/zellij#615 (comment)

[fdncred]

i can't reproduce it on linux either using wslg ubuntu with wayland

[hunger]

Did younuse zellij during your test? Or a container?

Nu works fine in a bog-standard terminal on Linux for me as well.

[fdncred]

As I said above, I used WSLg. It's not started as a child process of any other shell. If someone wants to submit a PR to somehow start nushell as a pid group, that works on Mac/Linux/Windows, we'll take a look at it. I myself, am not even sure this is possible since no one is spawning nushell, like in the Zellij example.

[midnightexigent]

hmm, very much not expert here, but if understand correctly, nushell rather needs to create a pid group for every process it spawns, that way ctrlc doesn't propagate to nushell itself.

From the explanation of the folks at zellij when dealing with the issue

nushell doesn't create a new process group when spawnning a process,
so all processes including the ones spwanned by us are in the same
foreground group. So if kernel will send signal to every member of this
group.

Since other shells do that I don't see why it would be impossible for nushell. I am not at all familiar with the internals, but if a core developer directs me to the crate/module that handles that, I can try to submit a PR

[fdncred]

Help me understand better because I don't follow this logic. I thought the problem isn't with nushell's spawned processes like plugins or externals. I thought the problem was with how nushell launched itself. Am I understanding that correctly?

Point me to how other shells do this and I'll take a look. BTW - That zellij command is for spawning externals, not for spawning zellij itself. Plus, I believe the call it uses to do that is unix-only.

[midnightexigent]

I am very much spitballing, this is solely based on my understanding of the small explanation by the zellij contributor (aka paragraph I quoted in my previous comment)

My understanding is that zellij 0.14 spawned a pane and shell as part of the same process group. Since nushell doesn't create a process group for its child processes, any command spawned by nushell is part of the same foreground group as nushell itself as well as its parent zellij pane. ctrlcing that command propagates the interruption signal to the zellij pane that holds the nushell session.

To circumvent that, they made it so the shell is part of its own process group, separating the parent pane from its shell.

---

Point me to how other shells do this and I'll take a look

idk... the same explanation by the zellij contributor makes it sound like other shells do it "nushell doesn't create a new process group when spawnning a process"

[midnightexigent]

just did some testing, here's what I found

• zellij 0.14 & nu 0.44

# launch nu in zellij and make it sleep 
$ env SHELL=nu zellij setup --clean
Welcome to Nushell 0.44.0 (type 'help' for more info)
nushell> ^sleep 8000

# on a separate console

$ pgrep -a sleep
57217 sleep 8000

# find the group id of the sleep process
$ ps -o pid,ppid,pgid,sid,cmd 57217
    PID    PPID    PGID     SID CMD
  57217   57069   57068   57068 sleep 8000

# list the processes associated with that group id
$ pgrep --pgroup=57068 -a
57068 /home/midnightexigent/.cargo/bin/zellij --server /run/user/1000/zellij/0.14.0/ubiquitous-addition
57069 /usr/bin/nu
57217 sleep 8000

process spawned by nushell finds itself in the same foreground group as the zellij session and nushell itself. ctrlc propagates to the zellij session, killing the pane

---

• zellij 0.26.1 & nu 0.44

# launch nu in zellij and make it sleep 
$ env SHELL=nu zellij setup --clean
Welcome to Nushell 0.44.0 (type 'help' for more info)
/home/midnightexigent> ^sleep 8000

# on a separate shell
$ pgrep -a sleep
57534 sleep 8000

$ ps -o pid,ppid,pgid,sid,cmd 57534
    PID    PPID    PGID     SID CMD
  57534   57478   57478   57478 sleep 8000

$ pgrep --pgroup=57478 -a
57478 /usr/bin/nu
57534 sleep 8000

this time nu and zellij session are in seperate process groups, so ctrlc doesn't propagate to the zellij session

---

• zsh

# put zsh to sleep
$ sleep 9000

# on a separate console
$ pgrep -a sleep
57968 sleep 9000
$ ps -o pid,ppid,pgid,sid,cmd 57968
    PID    PPID    PGID     SID CMD
  57968   51484   57968   51484 sleep 9000
$ pgrep --pgroup=57968 -a
57968 sleep 9000

zsh isn't in the same process group as the process it spawned, so ctrlc sends a signal to only the spawned command

[midnightexigent]

As to actually implementing this, shouldn't it be relatively straightforward if nushell forks itself before spawning a child process, then waits for the child ?

[midnightexigent]

Yeah so my last comment is no too far off from the truth. From tutorial on how to write a shell in C

First, an existing process forks itself into two separate ones. Then, the child uses exec() to replace itself with a new program. The parent process can continue doing other things, and it can even keep tabs on its children, using the system call wait().

int lsh_launch(char **args)
{
  pid_t pid, wpid;
  int status;

  pid = fork();
  if (pid == 0) {
    // Child process
    if (execvp(args[0], args) == -1) {
      perror("lsh");
    }
    exit(EXIT_FAILURE);
  } else if (pid < 0) {
    // Error forking
    perror("lsh");
  } else {
    // Parent process
    do {
      wpid = waitpid(pid, &status, WUNTRACED);
    } while (!WIFEXITED(status) && !WIFSIGNALED(status));
  }

  return 1;
}

[fdncred]

Something like this is worth a try on Linux and Mac but I think fork() still doesn't on Windows. We try to be cross-platform as much as possible but a PR may be accepted anyway.

[hunger]

I am not an expert when it comes to writing shells, but this is so low level that I would be seriously surprised if there was a good cross-platform solution for this:-/

[midnightexigent]

I'd leave it untouched on windows since the problem is no longer happening there. I don't think the concepts of process group or kernel signals translate from unix to windows very well either way

with the nix crate and conditional compilation it sounds straightforward. but IMO there's gonna be twist since builtin commands aren't other binaries meaning that they are technically the same process as nushell..

[ErichDonGubler]

I'm reproducing this issue (or one very similar) with Windows Terminal and the sleep command; if I hit CTRL + C during a sleep 10sec invocation, then it ends up terminating the entire shell:

Is this the same issue? Should I create another one?

[fdncred]

No issues in WezTerm on Mac.

[rgwood]

I'm reproducing this issue (or one very similar) with Windows Terminal and the sleep command

I can't reproduce this in Windows Terminal on v0.70.1, guessing it's been fixed.

Is anyone still having issues with ctrl+c crashing?

[hunger]

I still have exactly the same behavior I originally reported in nu 0.70.0. I do not see 0.70.1 when trying cargo install yet.

[kouhe3]

same issue here. Windows Terminal.

| key                | value                                    |
| ------------------ | ---------------------------------------- |
| version            | 0.77.1                                   |
| branch             |                                          |
| commit_hash        | 0120e4040d09f3bdffb945fa5fe450b72df7837a |
| build_os           | windows-x86_64                           |
| build_target       | x86_64-pc-windows-msvc                   |
| rust_version       | rustc 1.66.1 (90743e729 2023-01-10)      |
| rust_channel       | 1.66.1-x86_64-pc-windows-msvc            |
| cargo_version      | cargo 1.66.1 (ad779e08b 2023-01-10)      |
| build_time         | 2023-03-17 05:15:37 +00:00               |
| build_rust_channel | release                                  |
| features           | default, zip                             |
| installed_plugins  |                                          |

[NfNitLoop]

Some investigation: I wonder if this might just be a "feature" of Windows Terminal.

As a user, I expect ctrl-C to interrupt the "currently running thing". (be that a process, or a script running in my shell).

But I think Windows Terminal or PowerShell might just be killing the process. For example:

If in PowerShell I run:

PS C:\Users\Cody> nu
C:\Users\Cody〉sleep 5sec

and press Ctrl-C, NuShell gets killed and I'm dropped back to PowerShell.

BUT, if I start a new tab in Windows Terminal running NuShell directly, I can run:

C:\Users\Cody〉sleep 5sec

And pressing Ctrl-C brings me back to NuShell.

So it seems maybe PowerShell or Windows Terminal is just interpreting Ctrl-C as ... kill the running (OS) process? Or "Get me back to my shell"?

---

Or maybe it's expecting the running process (NuShell) to trap and respond to Ctrl-C within some timeline or it gets killed?

If I run nu from PowerShell, and it's NOT running a script/subprocess, I can Ctrl-C all I want and it just gets me a new prompt. (i.e.: it doesn't kill NuShell or exit back to PowerShell.)

[ChrisDenton]

I think the HandlerRoutine callback is relevant here. Specifically, using SetConsoleCtrlHandler to set one.

[rgwood]

I still can't reproduce this on Windows, unfortunately. sleep 5sec then ctrl+c does not terminate Nu for me in Windows Terminal (1.17.1023) or Alacritty (0.11.0). Launching Nu from PowerShell does not seem to make a difference.

@ChrisDenton I believe we're already calling SetConsoleCtrlHandler indirectly using the ctrlc crate:

nushell/src/signals.rs

Lines 12 to 14 in 7ec5f2f

	ctrlc::set_handler(move || {
	handler_ctrlc.store(true, Ordering::SeqCst);
	})

[sophiajt]

This issue is quite strange. Seemingly, no one on the nushell team has been able to reproduce this, which is leading me to think that there are other configuration components involved.

As no one on the team has been able to reproduce this, I'm going ahead and closing. If folks who are experiencing this are able to come up repro steps, please re-open and post the repro steps.

[kouhe3]

version | transpose                                                                           08/24/2023 10:48:51 AM
╭────┬────────────────────┬──────────────────────────────────────────╮
│  # │      column0       │                 column1                  │
├────┼────────────────────┼──────────────────────────────────────────┤
│  0 │ version            │ 0.83.1                                   │
│  1 │ branch             │                                          │
│  2 │ commit_hash        │ bf5bd3ff102689a3cae78ea5dfe2e67dfa92f4cd │
│  3 │ build_os           │ windows-x86_64                           │
│  4 │ build_target       │ x86_64-pc-windows-msvc                   │
│  5 │ rust_version       │ rustc 1.69.0 (84c898d65 2023-04-16)      │
│  6 │ rust_channel       │ 1.69.0-x86_64-pc-windows-msvc            │
│  7 │ cargo_version      │ cargo 1.69.0 (6e9a83356 2023-04-12)      │
│  8 │ build_time         │ 2023-07-30 18:18:41 +00:00               │
│  9 │ build_rust_channel │ release                                  │
│ 10 │ allocator          │ standard                                 │
│ 11 │ features           │ default, sqlite, trash, which, zip       │
│ 12 │ installed_plugins  │                                          │
╰────┴────────────────────┴──────────────────────────────────────────╯

video.mp4

[jupjohn]

I've been experiencing this for the past few months, and might have a solution for anyone who installed via a package manager like chocolatey or scoop (assuming scoop will do the same thing).

My alacritty config was pointing at C:\ProgramData\chocolatey\bin\nu.exe which it turns out isn't the nu binary - it's a shim that then executes the real binary at C:\Program Files\nu\bin\bu.exe. After I changed alacritty to use the real binary, the problem disappeared 🎉

Chocolatey generates these shims and I suspect they do some funky stuff around spawning that shell (although I'm not going to dig into it).