Control: retitle -1 libreadline8t64: the \C-u setting in .inputrc is ignored if ^U is the kill character
Control: found -1 8.2-6

On 2024-08-10 11:55:14 +0200, Vincent Lefevre wrote:

With

"\C-u": kill-whole-line

in the .inputrc file, if ^U is the kill character (usual tty settings),
\C-u kills only the characters before the cursor instead of the whole
line.

The real issue is actually that this

"\C-u": kill-whole-line

setting in the .inputrc file is ignored if ^U is the kill character.
I could check that by changing it to

"\C-u": backward-word

The setting is honored only after a "stty kill undef" *before* executing
the readline-based command (such as bash or gp).

--
Vincent Lef�vre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Control: retitle -1 libreadline8t64: inputrc settings should have the precedence over the tty settings (e.g. for the kill character ^U)

As a summary of the discussion at
https://lists.gnu.org/archive/html/bug-readline/2025-07/msg00014.html

More generally, the inputrc settings are ignored for the characters
present in the tty settings. In general, both settings are probably
consistent, but for the kill character, there is an ambiguity: both kill-whole-line and unix-line-discard match the tty kill behavior, as
in a tty, there cannot be characters after the cursor. Unfortunately, bash/readline chose unix-line-discard (kill-whole-line is closer to
the actual description, so that this is surprising), and this is not documented. In any case, whatever the choice done by bash/readline,
I suppose that a part of the users would prefer the other function.

The only clean solution to be able to override this choice (and
other tty settings, if need be) would be that the inputrc settings
should have the precedence over the tty settings. The readline
documentation does not explicitly say which one has the precedence,
but the intent, the logic and the practical usefulness seem to be
that the inputrc settings should have the precedence, which is not
the current behavior.

The only workaround is to set bind-tty-special-chars to Off in the
inputrc settings (e.g. ~/.inputrc file) with

set bind-tty-special-chars Off

In bash/readline, this was changed to On in the past (2005), because
some people complained that their tty settings were not honored, but
I suppose that under Debian, most users have standard tty settings.
Perhaps there could be some tests by Debian users. So I'm wondering
whether Debian should default this option to On.

--
Vincent Lef�vre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-07-10 22:44:51 +0200, Vincent Lefevre wrote:

The only workaround is to set bind-tty-special-chars to Off in the
inputrc settings (e.g. ~/.inputrc file) with

set bind-tty-special-chars Off

In bash/readline, this was changed to On in the past (2005), because
some people complained that their tty settings were not honored, but
I suppose that under Debian, most users have standard tty settings.
Perhaps there could be some tests by Debian users. So I'm wondering
whether Debian should default this option to On.

Of course, I meant that it should be set back to Off.

I haven't seen any drawback with both the default tty settings
and my tty settings (basically, with "stty -ixon").

--
Vincent Lef�vre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)