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 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 want a dummy separator character sequence. You should be able to supply > one. I am looking for a way to have a prompt string (that happens to end in a backslash) that works across all settings of bash, and the user can conveniently append to. I think at this point we all agree that there's no such value. (There _is_ such a value if I know the state of promptvars. This is what I think we will go with.) 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? > 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. But they weren't consistent either: whether \1 or \2 appeared in the output depended on PS0 vs. PS1, as well as readline vs. noediting. 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. > You want a new feature. Fine. Let's evaluate it as a new feature. I don't want a new feature. I want sanity, consistency. (And if from the sane, consistent behavior the workaround I'm hoping for doesn't arise then so be it, I'll look for another workaround. It's just that the -- IMHO -- sane, consistent behavior would coincidentally end up being a great workaround for our actual problem.) 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. The next two circumstances making a difference in the prompt's final appearance is something I cannot see an excuse for. It's a 2x2x2 cube with some of its corners looking the same. The recent change changed which ones are the same and which ones are different (plus how "extreme" the prompt string needs to be for them to be different), in a way that you see it as an improvement whlie I don't. I'd only consider the behavior consistent if no matter how extreme the prompt value, only 'promptvars' could have an effect on the final string. Look, I really don't want to push this any further. I know you are the main developer, and I can't see I'd be able to convince you. It's not worth more of my time to give it a super slim chance. I'll see what I can do with bash's current behavior. Thanks, e.
