On 2025-07-09 14:13:59 -0400, Chet Ramey wrote: > On 7/9/25 12:21 PM, Vincent Lefevre wrote: > > On 2025-07-09 11:40:17 -0400, Chet Ramey wrote: > > > On 7/9/25 10:56 AM, Vincent Lefevre wrote: > > > > A \C-u setting in the .inputrc file such as > > > > > > > > "\C-u": kill-whole-line > > > > > > > > is ignored if ^U is the kill character (usual tty settings). > > > > > > This is controlled by the readline variable `bind-tty-special-chars', > > > which is enabled by default. It's been that way since bash-3.1, which > > > was released in 2005. > > > > So, this should be the equivalent of the kill character, i.e. > > "erase the current line", which corresponds to kill-whole-line > > ("Kill all characters on the current line, no matter where > > point is"), but this is not what I get. > > It isn't, though. The readline equivalent of the stty VKILL character > is `unix-line-discard', which kills characters between point and the > beginning of the line. (That happens to be the default binding for ^U > in both emacs and vi modes).
The intent of the KILL character ("kill" in stty) is to erase the line, as clearly documented in the stty(1) man page: kill CHAR CHAR will erase the current line (otherwise it should have said "erase the characters (backward) up to the beginning of the line"). > This is what ^U does in (standalone) vi insert mode. Emacs does something > different with ^U, of course. Since you can't move around the line in > canonical Unix tty input, you're always at the end of the line and there's > no difference in the effect of the two behaviors. If you mean that there is an ambiguity between both, then bind-tty-special-chars (On) If set to On (the default), readline attempts to bind the control characters treated specially by the kernel's terminal driver to their readline equivalents. makes no sense for the KILL character as there would be 2 possible readline equivalents, and this cannot be deduced from the above description (the only way to disambiguate would be to take the stty(1) man page into account, but the readline behavior does not match the stty description, as I've said above). Moreover, the above documentation is incomplete as it does not say which has the precedence: the tty settings or the user's inputrc file. And concerning the actual behavior, giving the precedence to the tty settings as it does is a poor choice: if the user has some specific setting in their inputrc file, the goal is to use it[*]. IMHO, when bind-tty-special-chars is On, the tty settings should just have the precedence over the default bindings. [*] In practice, there would probably be no differences, but for the KILL character, there would be 2 variants: some users might prefer unix-line-discard and others might prefer kill-whole-line. That would be at least one reason why the inputrc file having the precedence would be important. Another point, in my stty settings, I have in particular: start = ^Q; stop = ^S but though bind-tty-special-chars is On, this is ignored by bash and readline (e.g. in gp), for which Ctrl-Q is quoted-insert and Ctrl-S is forward-search-history, i.e. their default bindings. This is fine for me, but does not behave as documented. -- Vincent Lefèvre <vinc...@vinc17.net> - 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)