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

[Lex Trotman]

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?

>
> Patch is 0001-VTE-Fix-killing-the-child.patch.
>
>
> 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?

> Now ^D.  An user expects ^D to send EOF to the stdin of the running
> child, whatever this might mean to that child;  not to behave like ^C
> and certainly not to reset the terminal/kill the shell.
>

Agreed as well.

> So, to summarize, I think it's important that both ^C and ^D end up
> being handled by the shell we run in the VTE, and not by us vainly
> trying to do something that looks like almost not so bad.
>
> I search a bit how I could forward ^C and ^D to the VTE child, and
> didn't find much in the VTE docs;  but Wikipedia told me that ASCII ETX
> and EOT were commonly respectively used to mean ^C and ^D for UNIX
> terminals [2] [3].  And indeed, sending those using
> `vte_terminal_feed_child()` seems to work just fine.  I however don't
> know how portable/reliable this is, so I ask for your knowledge and
> opinion here.
>

This vaguely triggers a memory of a previous discussion on this topic,
but I don't have time just now to search for it.


> Attached patch is
> 0002-VTE-Really-send-C-and-D-to-the-terminal-rather-than-.patch.
>
> Ah, and note that one can still reset the terminal like before through
> the context menu.
>
>
> So, have you opinions, ideas, remarks, something to say?  Looking
> forward to read you on the subject :)
>

Can you get any ideas from what the various terminal emulators that
use VTE do with these keycodes etc?

Cheers
Lex

> Regards,
> Colomban
>
>
> [1] and here we speak of the shell's child, not the VTE child which is
> the shell.
> [2] https://en.wikipedia.org/wiki/End-of-text_character
> [3] https://en.wikipedia.org/wiki/End-of-transmission_character
>
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>