Error when exiting with ^C under some shells

[michaelpj]

If I run bash -c 'cat $(ls | selecta)' and ^C out of the selecta prompt, then I get the following error:

/home/michaelpj/bin/selecta:782:in `block in command': Command failed: "stty 4500:5:bf:8a3b:3:1c:7f:15:4:0:1:ff:11:13:1a:ff:12:f:17:16:ff:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0\n" (RuntimeError)
        from /home/michaelpj/bin/selecta:779:in `pipe'
        from /home/michaelpj/bin/selecta:779:in `command'
        from /home/michaelpj/bin/selecta:772:in `stty'
        from /home/michaelpj/bin/selecta:565:in `restore_tty'
        from /home/michaelpj/bin/selecta:543:in `ensure in block in with_screen'
        from /home/michaelpj/bin/selecta:544:in `block in with_screen'
        from /home/michaelpj/bin/selecta:752:in `call'
        from /home/michaelpj/bin/selecta:752:in `with_tty'
        from /home/michaelpj/bin/selecta:536:in `with_screen'
        from /home/michaelpj/bin/selecta:44:in `main'
        from /home/michaelpj/bin/selecta:791:in `<main>'

If I try to run this in a bash shell directly, then I don't see the error, but my terminal becomes messed up: input stops appearing, but I can still enter commands.

I've tried with --norc --noprofile --noediting --posix, and that doesn't help.

I also see the error when I run zsh -c 'cat $(ls | selecta)', but have no problems running the command directly at a zsh prompt.

I don't see this using sh on my system (which is dash).

I'm sure this is some weird terminal interaction, but I'm afraid I don't have any more leads than that! In general, it seems to only happen when selecta is running inside a command substitution.

[rschmitt]

Are you on Linux? I noticed an issue with stty on Linux that doesn't occur on OS X:

rschmitt/heatseeker@6b2d27e#diff-a6432244543ebcd356024444b2fe297aR148

I'm not sure why you would only see this on ^C, however.

[garybernhardt]

It doesn't seem to be related to the newline from stty. On OS X Yosemite, I can reproduce the error when running via bash -c, but can't reproduce the terminal breakage when running directly.

[garybernhardt]

I just checked and this happens throughout Selecta's entire history. I suspect that it's something like: the shell is seeing the SIGINT first, starts cleaning up, and by the time Selecta sees it the TTY is already gone. But there must be some way to get around that, because fzf (which uses curses) doesn't have this problem.

[garybernhardt]

@michaelpj, can you try it on the raw_input branch? I changed the stty command to put the terminal in raw mode, which solves the problem for me, and hopefully for you. If that seems to work, I'll merge it to master.

(Note that with the version of the command using bash, hitting ^C only kills Selecta, not the whole pipeline. I don't think there's any good way to make ^C send SIGINT to the entire process group, as it normally would, but also fix this bug.)

[michaelpj]

Yep, that fixes it for me. Things now work as I expect when running bash -c. Running it in an actual bash terminal still has slightly odd behaviour - I have to ^C twice to get back to my prompt. I don't know whether that's due to what you mentioned about the SIGINT only killing selecta.

However, running my pipeline it via -c or in a script doesn't seem to have this problem - everything finishes up nicely. So this is good as far as I'm concerned!

[gshutler]

This changes behaviour in some of my scripts, this one for opening a file in vim for example.

Previously if I ^Ced within selecta it would drop back to the command prompt, now it proceeds to open vim. I'm guessing that's a side effect of it only killing selecta?

[gshutler]

I can alter my scripts to account for this easily enough, just thought I'd raise the change in behaviour that some people might be relying on at the moment.

[michaelpj]

Yes - on closer inspection that's also what I'm seeing, it's just that in this case I don't actually mind! It looks like the command substitution evaluates to an empty string, rather than killing the caller.

[garybernhardt]

Yes, the need for two ^Cs is the result of ^C only killing Selecta. Normally, ^C sends SIGINT to the entire foreground process group, which would contain the whole pipeline. With the terminal in raw mode, the ^C just shows up on the TTY and is read by Selecta.

Selecta could send SIGINT to its own process group in response to ^C. It's not even hard: Process.kill("INT", -Process.getpgrp()). However, this is scary.

Selecta does a lot of TTY stuff now, and I feel like I understand what it's doing. But signals and process hierarchies aren't my strong point. I'm not sure that an arbitrary process intercepting a ^C and then SIGINTing its own process group is right. It seems like it should be right, but this stuff is arcane and who knows? (Seriously, if someone knows, that would be great. ;)

[garybernhardt]

I created a gist showing a minimal, isolated version of the original problem. I'm still stumped, though. https://gist.github.com/garybernhardt/d496c69bf9e7cc03ddbd

[gshutler]

Well I now know more about subshells than I did at the start of the day. From what I can tell this is a feature of grouping commands in bash so scripts like mine linked above are working as expected.

What I should be doing if I want to use a subshell is generate the error myself. However, I've learnt about this all in the last half an hour so there could be nuances I don't know about.

[garybernhardt]

I just pushed another branch, raw_input_2, that seems to fix this. It does the send-SIGINT-to-process-group trick that I mentioned above. I was skeptical of that technique, but Glyph says that it will probably work (https://twitter.com/glyph/status/573617810913431552), and he knows a lot more about this stuff than me.

@gshutler and @michaelpj , can you try the raw_input_2 branch and see whether it acts as you'd expect? Selecta's behavior there should be exactly as it's always been, except without the initial issue reported by @michaelpj in this thread.

[gshutler]

👍

[michaelpj]

👍

[garybernhardt]

Merged into master in abee7d3. Thanks for the excellent bug report and help figuring it out.