It appears that the problem I am seeing is as a result of kernel code in
n_tty.c: (lines 355-367)
if (!L_ECHOK(tty) || !L_ECHOKE(tty) || !L_ECHOE(tty)) {
spin_lock_irqsave(&tty->read_lock, flags);
tty->read_cnt -= ((tty->read_head - tty->canon_head) &
(N_TTY_BUF_SIZE - 1));
tty->read_head = tty->canon_head;
spin_unlock_irqrestore(&tty->read_lock, flags);
finish_erasing(tty);
echo_char(KILL_CHAR(tty), tty);
/* Add a newline if ECHOK is on and ECHOKE is off. */
if (L_ECHOK(tty))
opost('\n', tty);
return;
}
According to this code (which is executed whenever a kill character is
received in canon mode on the tty), if any of echok/echoke/echoe is off,
the tty will not erase the line. Instead, it will simply echo the kill
character (obeying echoctl) and optionally a newline (if echok is set).
This is not the correct behavior. A patch has been sent to linux-kernel
for discussion.
Regardless of this, however, gnome-pty-helper SHOULD be setting echok.
The kernel has it set in the default tty parameters, and most terminal
emulators only edit these parameters slightly, if at all. For example:
xterm: Uses kernel defaults
rxvt: Uses stty defaults (kernel defaults + brkint + imaxbel)
eterm: Uses stty defaults
aterm: Uses stty defaults
Note that powershell exhibits the same bug because it also depends on
libzvt2.
I think this is compelling evidence that it is normal, and even
_expected_, that echok be set on a default tty.
Therefore gnome-pty-helper should be patched to enable it.
If you disagree, please present your arguments against this.
--
Taral <taral@taral.net>
Please use PGP/GPG encryption to send me mail.
"Any technology, no matter how primitive, is magic to those who don't
understand it." -- Florence Ambrose
Attachment:
pgp0nBVwes_K8.pgp
Description: PGP signature