On 6/12/26 2:46 PM, Egmont Koblinger wrote:
On Fri, Jun 12, 2026 at 8:13 PM Chet Ramey <[email protected]> wrote:OK. Prompt strings that are passed to readline have \[ and \] replaced with \1 and \2, respectively, since those characters mean something to readline. If they are not passed to readline, they don't. I think that's consistent from a behavior perspective.Eliminating \[ \] before vs. after the promptvars expansion is not the same. I opened this very thread with examples of the prompt in the readline vs. noediting cases looking vastly differently.
Not really. You opened it with https://lists.gnu.org/archive/html/bug-bash/2026-05/msg00061.html which mentions that the 0x01 and 0x02 markers produce replacement symbols on some terminal emulators.
Not really. You have identified the problem -- the supplied PS0 ending in a backslash that might have an unintended meaning if a user appends to it.... combined with the inconvenience that depending on 'promptvars' we would need to escape it differently in order to prevent spillover to the user-added segment.
You have a couple of alternatives, then. Require promptvars, or add some other dummy sequence to prevent the backslash being the final character.
Are you really trying to put the burden on us to use a dummy (a brand new no-op escape sequence ignored by vte, designed for this very purpose) because bash is unable to compose the string we really wish to emit?
I am trying to find a solution that doesn't require new code, and doesn't require you to wait two years until vendors adopt bash-5.4 (whenever that gets released).
And they were: they expanded to \1 and \2 just like in PS1. You simply didn't like the result, since it was not ignored by all terminals.Not being ignored by all terminals is one thing, not even liking a semantical misuse of those bytes in vte is another.
We agree they shouldn't be in the prompt string unless they'll be passed to readline. What you want is something to prevent the backslash terminator from escaping the next character.
Plus you have to dig deep into bash's _and_ readline's documentation to realize that a \[ \] in the prompt ends in \1 or \2 getting emitted.
Right. They shouldn't be there at all if the string's not going to be passed to readline. This was the --noediting case all along.
I don't want a new feature. I want sanity, consistency.
You call it what you like. You want new code, and no one is stepping up to write it.
The way the prompt variables are _exactly_ converted to their final user-facing strings depends on (at least) three circumstances: - promptvars - readline vs. noediting - PS0/4 vs. PS1/2 (Well, as of recently, bash's version is a fourth circumstance, but it's inevitable if we're changing anything.) Having the first one, `promptvars` in place is already bad, but I can accept it has its legacy reasons.
Well, you've had 37 years to get used to it.
The next two circumstances making a difference in the prompt's final appearance is something I cannot see an excuse for.
OK, I think we're both interested in finding a path forward that works
differently than bash-5.3. My guess is you're going to end up requiring
promptvars to be set, which is the bash default anyway.
--
``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
