[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should the readline *-meta flags reset when $LANG changes?

From: Chet Ramey
Subject: Re: Should the readline *-meta flags reset when $LANG changes?
Date: Wed, 10 Aug 2022 10:21:18 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

On 8/9/22 4:50 PM, Koichi Murase wrote:
> 2022年8月10日(水) 2:07 Alan Coopersmith <alan.coopersmith@oracle.com>:
>>>> Thanks for the report. The eight-bit settings are auto-set once, when
>>>> readline is first called, but I'll see if it makes sense to change them
>>>> on every call.
>>> It's fairly easy. I'll make the change for the next devel branch push and
>>> bash-5.2-rc3.
>> Thanks for the quick investigation!
> Does it mean custom values of these readline variables will be lost
> every time LANG or LC_{CTYPE,ALL} is changed even if a user or program
> intentionally sets them up?

It means those settings will now mirror the locale.

> We often temporarily change LANG or LC_* to perform some binary
> operations [such as counting the number of bytes of data and safely
> removing trailing x from the result of $(command;printf x)]. 

Do you often do this in interactive shells? Often enough to make a
difference? Across multiple calls to readline? And, if the change is
intended to be temporary, why would you not want the relevant
readline variables to reflect the locale when you were finished?

> Also, if these readline variables would be cleared every time, it
> seems to me that these readline variables would be effectively
> unconfigurable and would lose the point of their existence, or we
> could not touch LANG or LC_* at all after the initial setup.

It seems to me that the scenario Alan describes is much more common.

> Is it possible to make three states of the readline variables,
> `on/off/auto', and make `auto' the default, which determines the
> behavior depending on the current locale? In this case, the actual
> behavior on/off can be cached in another variable and can be updated
> on the change of LANG/LC_* when the readline variable has the value
> `auto'.

I'm not going to make this much of a change at this point in the release
process. I was willing to make the change I did because the changed
behavior is a superset of the previous behavior.

So, assuming we say that the scenario Alan outlined is reasonable (it is),
it looks like there are four alternatives:

1. Do nothing; maintain the bash-5.1 behavior and force the change to the

2. Leave the new function in place; automatically adjust to locale

3. Push it off to the application: introduce a new readline API that
   applications can call when locale variables change. This is very cheap.

4. Push it onto readline: instead of checking the locale and making the
   eight-bit variables mirror it on each call, make readline check for
   locale changes (well, LC_CTYPE) and reset the eight-bit variables only
   if the current value doesn't match the value from the last call.

The last option is about as much of a change as I'm willing to make at
this point.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]