[Geany-Devel] VTE resetting and handling of ^C and ^D

[Colomban Wendling]

Le 04/12/2012 23:36, Lex Trotman a écrit :
> On 5 December 2012 09:18, Colomban Wendling <lists.ban at 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&group_id=153444&atid=787791
>> (I think improperly marked as fixed)
>>  *
>> https://sourceforge.net/tracker/index.php?func=detail&aid=3518151&group_id=153444&atid=787791
>>
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-VTE-Always-let-the-terminal-handle-C-and-D-itself.patch
Type: text/x-patch
Size: 3860 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20121205/3996e7ed/attachment.bin>