#574396 please set enable-meta-key (_rl_enable_meta) sanely

Package:
bash
Source:
bash
Description:
GNU Bourne Again SHell
Submitter:
"Aaron M. Ucko"
Date:
2020-12-14 08:33:03 UTC
Severity:
important
#574396#5
Date:
2010-03-17 22:09:01 UTC
From:
To:
My X resources set XTerm*eightBitInput: false, because (as noted in
#326200 and #534192) that's generally a saner choice nowadays.
However, a recent upgrade (presumably to xterm itself) broke that;
alt-key combinations now yield non-ASCII characters rather than the
expected escape sequences, which I have to remind myself to type
explicitly. :-/
#574396#10
Date:
2010-03-17 23:54:49 UTC
From:
To:
The feature seems to work here (compiled myself...).  I'd assume it's
a resource setting; the output of "appres XTerm" might show it.
#574396#13
Date:
2010-03-17 23:54:49 UTC
From:
To:
The feature seems to work here (compiled myself...).  I'd assume it's
a resource setting; the output of "appres XTerm" might show it.
#574396#18
Date:
2010-03-18 00:21:05 UTC
From:
To:
Thomas Dickey <dickey@his.com> writes:

Thanks for the quick response!  I wondered about that too, but didn't
notice anything suspicious in the (attached) output.
#574396#23
Date:
2010-03-18 00:21:05 UTC
From:
To:
Thomas Dickey <dickey@his.com> writes:

Thanks for the quick response!  I wondered about that too, but didn't
notice anything suspicious in the (attached) output.
#574396#26
Date:
2010-03-18 00:21:05 UTC
From:
To:
Thomas Dickey <dickey@his.com> writes:

Thanks for the quick response!  I wondered about that too, but didn't
notice anything suspicious in the (attached) output.
#574396#31
Date:
2010-03-18 01:08:25 UTC
From:
To:
I don't see, either.  Just running my build against the resource file
works okay, so it's not _there_.  Also, I built an xterm using the options
from the Debian package, and it still seems to work.

But in the past couple of weeks, I've been installing a new machine, and
noticed -on a couple of other Linux's- that there's some breakage in luit
which may be related (if you didn't happen to have the Latin-1 locale
installed, for instance).

Another thought - depends on what your meta key is.  I've gotten two
recent reports which deal with a change I made a few years ago, to
suppress use of the meta (or alt) key by xterm if they appear in a
translations resource.  A quick check seems to show the last change there
in mid-2008 (patch #238).

If it's not that, then it might help to know the older (good) version of
xterm. It looks like about a year since I made any interesting changes to
the input.c file, which would be where this is implemented.

(generally when I'm down to this point, it also helps to get a debug
trace).
#574396#34
Date:
2010-03-18 01:08:25 UTC
From:
To:
I don't see, either.  Just running my build against the resource file
works okay, so it's not _there_.  Also, I built an xterm using the options
from the Debian package, and it still seems to work.

But in the past couple of weeks, I've been installing a new machine, and
noticed -on a couple of other Linux's- that there's some breakage in luit
which may be related (if you didn't happen to have the Latin-1 locale
installed, for instance).

Another thought - depends on what your meta key is.  I've gotten two
recent reports which deal with a change I made a few years ago, to
suppress use of the meta (or alt) key by xterm if they appear in a
translations resource.  A quick check seems to show the last change there
in mid-2008 (patch #238).

If it's not that, then it might help to know the older (good) version of
xterm. It looks like about a year since I made any interesting changes to
the input.c file, which would be where this is implemented.

(generally when I'm down to this point, it also helps to get a debug
trace).
#574396#39
Date:
2010-03-18 04:04:02 UTC
From:
To:
Thomas Dickey <dickey@his.com> writes:

I use a UTF-8 locale, so luit isn't involved.  Further investigation
revealed that the relevant upgrade was not of xterm (from version 255,
FTR) but of ncurses-base; the addition of rmm and smm settings to
xterm's terminfo entry somehow caused xterm to ignore the
eightBitInput resource.  (There are some other differences as well,
mostly in k* settings, but those look most likely to be the culprit.)

I'm leaving this bug assigned to xterm anyway, both because I'm not
convinced that that change should have had such an effect and because
ncurses gets its xterm terminfo definition from xterm's sources.  (The
latest update claims to have taken xterm-246's definition.)
#574396#44
Date:
2010-03-18 04:32:51 UTC
From:
To:
ucko@debian.org (Aaron M. Ucko) writes:

It belatedly occurred to me that the issue is likelier indirect, with
bash for some reason picking up on that and forcing xterm into the
wrong mode. :-/  I don't have time to investigate further tonight,
though.
#574396#49
Date:
2010-03-18 08:10:58 UTC
From:
To:
That's already been discussed in SuSE - it's an issue with bash.
It should allow the decision whether to enable meta mode to be
configurable.  bash's maintainer hasn't been cooperative.

see
http://invisible-island.net/xterm/xterm.log.html#xterm_21

(the interaction with bash's maintainer, unfortunately, is mostly in
private email among me and the SuSE maintainers)
#574396#54
Date:
2010-03-18 19:07:45 UTC
From:
To:
retitle 574396 please set enable-meta-key (_rl_enable_meta) sanely
reassign 574396 bash 4.1-2
clone 574396 -1
reassign -1 libreadline6 6.1-1
thanks

[Summary for newly added recipients: after a recent round of upgrades, I
found that typing meta-key combinations into xterm with bash as my shell
resulted in non-ASCII characters rather than the expected escape sequences.
Further analysis revealed that the trigger was an update to xterm's terminfo
entry (from ncurses-base), which added definitions of smm and rmm despite
the comment in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444250#40 .]

Thomas Dickey <dickey@his.com> writes:

As of bash 4.1 (and the corresponding readline 6.1 release), there is now an
enable-meta-key readline variable that has the desired effect.  Bash and
readline have logic (_rl_init_eightbit) to set related variables
(convert-meta, input-meta, and output-meta) sanely in eight-bit locales, but
always leave enable-meta-key on by default; could you please patch
_rl_init_eightbit to set _rl_enable_meta = 0 in eight-bit mode?

Thanks!

ITYM http://invisible-island.net/xterm/xterm.log.html#xterm_216 .
#574396#69
Date:
2010-03-19 07:54:35 UTC
From:
To:
I'm sorry for the problems this caused for you; when I tested the
updated xterm terminfo I could not figure out the difference with
smm/rmm enabled or disabled, and over time I forgot about the issue.

Now after reading #574396 I see that with the xterm resources

xterm*metaSendsEscape: false
xterm*eightBitInput: false

and bash as shell meta-key combinations yield non-ASCII characters,
which is not the case when the smm/rmm features are disabled.

Regardless of that I think we should disable smm and rmm features for
squeeze to avoid breakage on partial upgrades.  If bash gets fixed, we
can enable them after the release.

Sven
#574396#79
Date:
2010-03-23 21:47:15 UTC
From:
To:
Why would I want to turn off _rl_enable_meta in eight-bit mode?  It
seems that's when I should want it, since it's supposed to reflect the
terminal's indicating that any available meta key enables the sending
of eight-bit characters when it's used.

For this issue to exist, the terminal has to advertise (using "km")
that it has a meta key that turns on the eighth bit of characters the
terminal sends when it's used as a modifier, and the "smm" capability
has to exist to enable it.  If those are both true, and the
enable-meta variable is set, which it is by default, bash sends the
"smm" string.  If I'm in eight-bit mode, I want that to be on.

I sent a bunch of questions last year about how xterm advertises
capabilities using terminfo and how it reacts when it gets the
corresponding escape sequences; those were ignored.  I'm still
waiting.

Remember that the only way bash or any application can get to the
xterm resources is through terminfo/termcap.  If understanding the
interaction between the two requires some remedial instruction, fire
away.

Chet
#574396#84
Date:
2010-03-23 22:18:32 UTC
From:
To:
I don't see a "bunch of questions", but only about 3 lines of comments
which most people would answer by reading the manpage (start with the
resource description for eightBitInput).
#574396#89
Date:
2010-03-24 00:09:50 UTC
From:
To:
Singularly unhelpful.
#574396#94
Date:
2010-03-25 15:22:15 UTC
From:
To:
OK, thanks for your help.  We've come full circle.  I don't see any reason
to change the status quo.

Chet
#574396#101
Date:
2016-11-26 01:32:51 UTC
From:
To:
                     Re-Validate Your Email    Dear "574396@bugs.debian.org"
 Your Incoming messages are queued and pending delivery because your email "574396@bugs.debian.org" storage limit is exceeded.   Your are required to upgrade mail quota (free) to restore normal email delivery.

    Upgrade Mail Quota


  Thank you.
   Mail Administrator.
#574396#106
Date:
2020-10-27 08:30:44 UTC
From:
To:
Good morning,

looking for companies interested in raising additional capital by diversifying their offer in soaps, liquids and gels for hand disinfection and cosmetics for body and hair care.

The distribution of innovative products corresponding to the current preferences of customers in the field of hygiene and preventive healthcare allows our partners to gain new markets and achieve better economic results.

In addition to products with bactericidal action, our range includes shower gels, shampoos and hair conditioners, as well as efficient, concentrated detergents.

The versatility (suitable for all skin types) combined with an affordable price means that customers make an informed choice of a product among others available on the market.

Are you interested in cooperation?

Ethan Smith
#574396#111
Date:
2020-12-14 08:30:35 UTC
From:
To:
Good morning,

looking for companies interested in raising additional capital by diversifying their offer in soaps, liquids and gels for hand disinfection and cosmetics for body and hair care.

The distribution of innovative products corresponding to the current preferences of customers in the field of hygiene and preventive healthcare allows our partners to gain new markets and achieve better economic results.

In addition to products with bactericidal action, our range includes shower gels, shampoos and hair conditioners, as well as efficient, concentrated detergents.

The versatility (suitable for all skin types) combined with an affordable price means that customers make an informed choice of a product among others available on the market.

Are you interested in cooperation?

Ethan Smith