Le 04/12/2012 23:36, Lex Trotman a écrit :
On 5 December 2012 09:18, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hey,
When looking to the VTE code to fix focusing upon middle click, I also dig into the long-running problems we have on dealing with ^C and ^D.
First, we try to kill the child (the shell we launched) using SIGINT, but neither BASH nor DASH seem to honor them this way, so we actually only reset the view, thus leading to report like:
https://sourceforge.net/tracker/index.php?func=detail&aid=2623225&gr... (I think improperly marked as fixed)
https://sourceforge.net/tracker/index.php?func=detail&aid=3518151&gr...
You can check it if you want, either by sending SIGINT to a manually-launched BASH or by checking whether the pid actually quit. Anyway, you'll see nothing gets killed.
So, I propose to replace this by a SIGHUP. I attached a patch that does it, and it works; but I'm not 100% sure if it's OK to do so, although I don't see much problem with it.
Doesn't this screw up child processes that do something on sigint, since they won't get it now?
Well, we send this signal to the shell we launched and it only, so I expect the shell do what's needed to kill its children. I guess shells are supposed to handle this since it's the old "tty disconnect" signal; and at least Bash saves its history and quits with this one (whereas it doesn't quit with SIGINT and doesn't (obviously) save its history with SIGKILL). If you know a better signal, I'm all ears :)
The other problem is that we reset the terminal upon ^C -- and worse, upon ^D. OK, ^C is used to send SIGINT to the running child, which generally result in it exiting. But first, one generally expect it to only kill the running child [1], and not the terminal itself; and this is important e.g. if the user still want to read the output (e.g. if a program went wild, it may still have output useful errors). And then, legitimate programs handle SIGINT somewhat gracefully -- the excessive example being Nano which uses ^C as a shortcut.
So, I don't think ^C should reset the terminal/kill the shell, but rather be handled by the shell.
agreed, what happens if we actually send it to the shell?
The "problem" is that Geany has a global key handling function that will eat the event before they reach the VTE handler (which will simply send them to the child, as they should).
Though, your remark made me go in that function an realize it'd be quite easy to force it to let ^C and ^D pass through when on the VTE -- there is already quite some code for the VTE here.
So I now have a better patch that simply makes ^C and ^D pass through in any case, no matter "override Geany keybindings" is enabled or not -- since when it is ^C and ^D goes through properly. This approach looks indeed ways better, doesn't involves weird ASCII control characters, and removes quite some code -- and the code is slightly cleaner than before, although the check for ^C and ^D are spread across 2 files (instead of being spread across 2 functions in the same file).
Here's the revised patch (with a revised name): 0001-VTE-Always-let-the-terminal-handle-C-and-D-itself.patch
I think this patch is good (for now, hehe :D), but maybe we want let the other common binding pass through too, like ^Z, maybe others?
[...]
Can you get any ideas from what the various terminal emulators that use VTE do with these keycodes etc?
Nothing, they just let the keybinding go through I guess.
Regards, Colomban