On 6/14/26 9:26 PM, Koichi Murase wrote:
That doesn't work with «shopt -u promptvars». If it were the user's personal setting, the user should just turn on `promptvars', but we are now talking about interactive shell settings injected by the terminal, which need to work with various user configurations.Document your assumptions. Tell the user that there are caveats if they change the default bash settings, or the settings that you assume.That would be one solution, but my point is that we do not even need to tell the users if we just switch to another way of processing,
Seems to me you're already there: https://lists.gnu.org/archive/html/bug-bash/2026-05/msg00061.html says "This made me realize that we indeed do already rely on promptvars elsewhere (in PS1's value)." Since you already rely on promptvars being enabled, that gives you a solution: you can reliably insert the correct number of backslashes and count on the promptvars behavior to strip them as you want. Since any change I make won't be in a release until bash-5.4, and then you'll have to wait a year or two until it's widespread enough to count on, a solution that doesn't need changes to bash is better anyway.
You want a magic, invisible separator character that bash adds and deletes for you. That is not what \[ and \] are.No. We just want an additional step of processing PS0 and PS4, where \1\2 (including the ones that don't originate from \[\]) in the input is not inserted in the output.
Yes. You want \[ and \] (in particular) to insert a separator character, removed when the prompt isn't passed to readline. If you didn't want them as separators, to solve this niche problem, it wouldn't matter whether they appeared or not.
However, even if we forget about the original motivation, I think the detailed implementation of the change in 1e9f5e10 is undesired because it changes how `promptvars' has been applied to PS0 and PS4. By removing \1\2, strings that wasn't expanded by `promptvars' before commit 1e9f5e10 started to be expanded.
OK, then there is space for another implementation, waiting for someone to write it.
Actually, maybe we should now request reverting the \[\] change in 1e9f5e10. No one desired the behavior of the current devel change in 1e9f5e10,
Well, it satisfies the original request.
Technically, we don't have to make them identical. It is just more understandable and not surprising to produce the same strings to be sent to the terminal. Conversely, is there a reason to force PS0 to be different from PS1?
Sure, the same reason: PS0 is simply written to the terminal once, and
PS1 is passed to readline, which has its own requirements.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
