In my .inputrc I have the following lines: "\M-n": history-search-forward "\M-p": history-search-backward "\C-u": kill-whole-line With readline 5.0 they work fine, but with 5.1 they don't work. Oddly, if I bind to macros, e.g. "\C-u": "foo" it works fine. Also, I can make the first two work by using "\en": history-search-forward "\ep": history-search-backward I can get some Ctrl-letter keys to work by doing things like: "\x1": kill-whole-line # binds C-a to kill-whole-line but \x15 does not work as expected (trying various codes indicates that most C-letters can be bound in this way, but a few can't).
I'm using xterm and LANG=en_GB.UTF-8.
It doesn't work either here. I've tried with various locales (ISO-8859-1 and UTF-8 ones) and various terminals.
This is related to the tty settings. If I do a "stty kill undef", then the "\C-u": kill-whole-line is taken into account. A "stty kill ^u" makes it fail again.
Confirmed. I'm not clear on whether that should be happening. And this seems to have no bearing on bindings such as "\M-p", which still don't work.
This bug still exists, but I'm no longer sure to which package it should be assigned. I come across the bug in bash 4.2, which doesn't seem to depend on any version of libreadline now (e.g. bash 4.2-5).
It seems that bash now includes its own version of the GNU Readline library. Perhaps the bug should be cloned... The build dependency on readline for bash was removed here: bash (2.05b-2-11) unstable; urgency=medium [...] * Remove build dependency on readline (closes: #215165). [...] -- Matthias Klose <doko@debian.org> Tue, 14 Oct 2003 20:37:23 +0200 But you reported the bug in 2006. When you said "With readline 5.0 they work fine, but with 5.1 they don't work.", do you remember how you tested that? Anyway I can reproduce the Ctrl-u bug with pari-gp, which depends on libreadline6 (note that this bug is still assigned to libreadline5).
Yes, I had it working on readline 5.0, and when 5.1 was released, it no longer worked. libreadline5 seems to be used by few programs now, so it's not so important. I think it's most important that it be filed against libreadline6 and bash. However, since it's likely to be the same bug in libreadline5 and libreadline6, and also because it seems logical, maybe it should be cloned both to bash and libreadline6? Or assigned to libreadline6 and cloned to bash and libreadline5?
found 363502 5.2+dfsg-2 thanks I've checked that it still occurs with libreadline5 by installing units from squeeze. I could also reproduce the bug with clisp, whose unstable version still depends on libreadline5 (but I'm not sure that it really uses the library, as ldd doesn't list it). I think that the bug should be cloned twice, and have 2 reassign's (I don't know which package is best for the original bug number).
I hope you're saying you're going to make the decision, because I'm sure you know the Debian BTS better than I! I would say the original new bug should be against libreadline6, as a) that's the most important package to fix it in, and b) if it remains open for a long time, it won't risk being accidentally closed if e.g. libreadline5 disappears in the next release.
Control: clone -1 -2 -3 Control: reassign -1 libreadline6 Control: retitle -1 libreadline6: Something is wrong with binding keys to functions Control: found -1 6.2+dfsg-0.1 Control: reassign -3 bash Control: retitle -3 bash (readline): Something is wrong with binding keys to functions Control: found -3 4.2+dfsg-1 Not sure, but there are sometimes some surprises. OK. But as the initial contents are the same (really cloned), I don't think that there is much difference (mainly for existing references to this bug number).
Version: 5.2.21-2.1 Hi, this issue does not seem to affect version 5.2.21 of bash and libreadline8 version 8.2-4. Please reopen this bug if you can still reproduce this issue. Regards,
Control: reopen -1
Control: found -1 5.2.21-2.1
\C-u is still broken: it kills only the characters before the cursor
instead of the whole line as documented in the bash(1) man page:
kill-whole-line
Kill all characters on the current line, no matter where point is.
history-search-forward and history-search-backward seem also buggy, but it may be a documentation issue (they behave in a slightly different way). These issues are still present in readline. I've just reported the following bug against libreadline8t64 for \C-u: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078428 (the old bugs in obsolete readline binary packages had been closed).
On Sat, 10 Aug 2024 at 10:03, Debian Bug Tracking System < owner@bugs.debian.org> wrote: Thank for looking into this issue! I just tried on my Bookworm system (bash 5.2.15-2+b7) and the bug with \M-p and \M-n still seems present there. I can't see anything in the Changelog since then that would suggest a fix. I also checked the upstream bash changelog, and found nothing relevant there; but since it's a libreadline bug, that's not surprising. Bash, as far as I can tell, is not dynamically linked against libreadline8. So to test libreadline8, I tested Lua 5.4 (built from source against the system libreadline8, in my case libreadline8 version 8.2-1.3). I think this is sufficient then to reopen the bug, since it's the same version of libreadline8 upstream as you tested, and I can't see anything in the Debian changelog since -1.3 that would have affected this bug. Again, \M-n and \M-p do not work. (I did not test the separate problem with \C-u, but Vincent Lefèvre has addressed that.)
For \M-p and \M-n, this may be a documentation inaccuracy. The readline(3readline) man page says An Emacs-style notation is used to denote keystrokes. Control keys are denoted by C-key, e.g., C-n means Control-N. Similarly, meta keys are denoted by M-key, so M-x means Meta-X. (On keyboards without a meta key, M-x means ESC x, i.e., press the Escape key then the x key. This makes ESC the meta prefix. The combination M-C-x means ESC-Control-x, or press the Escape key then hold the Control key while pressing the x key.) However, even if the keyboard has a Meta key, it has the effect to generate an Escape character, so that one should use the \e form in the .inputrc file. For instance, with "\ep": history-search-backward M-p does a history-search-backward with libreadline8 (I've tried with gp from the pari-gp package). I think that this is just a notation issue. In GNU Emacs, if I type ESC x, then M-x is displayed. Perhaps readline should make \M- equivalent to \e for the .inputrc file. The behavior is the same in bash. BTW, with the default bindings, "bind -p" shows only \e forms; there are no bindings with "\M-". And note that if I use "\M-p": history-search-backward in the .inputrc file, "bind -p" gives for this binding: "\360": history-search-backward This is the octal value of the ASCII code of the character "p" (\160) with the 8th bit set (→ \360). AFAIK, setting the 8th bit was an old, optional way the Meta key was behaving with xterm, but with the non-ASCII locales, this is now completely obsolete.
I'm not quite sure I understand you here: are you saying that it's documented somewhere that one should use the "\e" form? Or is this just your assertion, in which case, on what do you base it? As I said, I tried something similar. Perhaps readline should make \M- equivalent to \e for the .inputrc As I said in my original report, "\M-" worked fine in readline 5.0. So as far as I can tell, it's a regression. In any case, I can't see any sense in requiring \e for some keys and not others. In any case, sounds like the issue should go upstream at this point?
I'm saying that since the documentation says that the Meta key
may generate an Escape character (which is actually the case in
general), you should use the \e form as a consequence.
I think that knowing how things work exactly is complex due to
the various variables. From the readline(3readline) man page,
in particular:
convert-meta (On)
If set to On, readline will convert characters with the eighth
bit set to an ASCII key sequence by stripping the eighth bit and
prefixing it with an escape character (in effect, using escape as
the meta prefix). The default is On, but readline will set it to
Off if the locale contains eight-bit characters. This variable
is dependent on the LC_CTYPE locale category, and may change if
the locale is changed.
enable-meta-key (On)
When set to On, readline will try to enable any meta modifier key
the terminal claims to support when it is called. On many termi‐
nals, the meta key is used to send eight-bit characters.
(Note: This is wrong, nowadays, the Meta key generates an Escape
character.)
input-meta (Off)
If set to On, readline will enable eight-bit input (that is, it
will not clear the eighth bit in the characters it reads), re‐
gardless of what the terminal claims it can support. The name
meta-flag is a synonym for this variable. The default is Off,
but readline will set it to On if the locale contains eight-bit
characters. This variable is dependent on the LC_CTYPE locale
category, and may change if the locale is changed.
Indeed, you said:
"With readline 5.0 they work fine, but with 5.1 they don't work."
In the CHANGES file:
------------------------------------------------------------------------
This document details the changes between this version, readline-5.1,
and the previous version, readline-5.0.
[...]
m. Fixed a bug that caused "\M-x" style key bindings to not obey the setting
of the `convert-meta' variable.
------------------------------------------------------------------------
So you can get the previous behavior about the .inputrc file with
set convert-meta On
but this means that non-ASCII characters (i.e. with the 8th bit set)
will be regarded as ASCII characters with the Meta key.
I suppose that this was historical. IMHO, any behavior based on the
8th bit should be removed. Nowadays, the 8th bit should be used for
non-ASCII characters, not to provide meta key information. This
would mean that "\M-" in the .inputrc file should behave like "\e".
At http://www.catb.org/esr/jargon/html/M/meta-bit.html it is written meta bit: n. The top bit of an 8-bit character, which is on in character values 128--255. Also called high bit, alt bit. Some terminals and consoles (see space-cadet keyboard) have a META shift key. [...]-------- That's probably why readline regards "\M-" as setting the meta bit, i.e. the 8th bit. This could be useful with the ASCII charset, where the 8th bit could be stripped by the terminal and interpreted in some special way (e.g. "\M-" commands), but this no longer makes any sense with true characters having the 8th bit set.
OK, I'm not sure I follow why this should be necessary (e.g. it isn't with Emacs), but I think I can now follow why it happens! convert-meta (On) This is also confusing. I read this and thought "OK, so convert-meta should be On in my UTF-8 locale, because UTF-8 doesn't have 8-bit characters", but it is off, so I guess UTF-8 counts as having 8-bit characters? I guess that warrants an upstream bug report; I'm happy to file it. m. Fixed a bug that caused "\M-x" style key bindings to not obey the Aha! Many thanks for your detailed explanation. I guess the question in 2024 is, can we have our cake and eat it? I think it would be nice if things worked as one might reasonably expect (i.e. "\M-" prefixes work as in Emacs) in UTF-8 locales. I can see that it might be complicated to make them work also in old terminals. But the convert-meta distinction would seem to be otiose in wide-character environments. I'm happy to take this to the readline mailing list if that seems appropriate; in any case, I guess this Debian bug can be closed, because in fact it's a deliberate change to readline 5.1.
About the bug with \C-u, the real issue (both in bash and readline) is actually that the \C-u setting such as "\C-u": kill-whole-line in the .inputrc file is ignored if ^U is the kill character. I could check that by changing this setting to "\C-u": backward-word Either setting is honored only after a "stty kill undef" *before* executing the command (such as bash or the readline-based gp). I've also mentioned that at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078428#10 for libreadline8t64.