Hi Chet, Thanks for accepting and working on my recent request at https://lists.gnu.org/archive/html/bug-bash/2026-05/msg00061.html which you aimed to address in commit 1e9f5e10b2a6f81d458936372380c870f0722ef1.
Unfortunately, the new behavior of \[ \] in PS0 is still not identical to their behavior in PS1. In PS1, the string undergoes two rounds of parsing (the second only if promptvars is enabled) and finally the 0x01 / 0x02 bytes (previously \[ and \] strings in PS1) are eliminated. (Thanks for pointing out that this is done in readline which is bypassed by PS0.) In PS0, it seems to me that the elimination of these markers now happens between the two rounds of parsing. In the following examples I assume that promptvars is enabled and that the terminal silently ignores the 0x01 / 0x02 bytes. Example 1: PS1='$\[PATH' The literal string $PATH (five characters) appears as prompt. Do the same with PS0. Prior to the recent change, the behavior was the same (under the hood with an invisible 0x01 byte after the dollar). With the new change, the long expanded value of $PATH is printed. Example 2: PS1='\\\[\\' The prompt is two backslashes. Assign the same value to PS0. Prior to this change, two backslashes appear. With the new change only one backslash is printed. Semantically (and also compatibility-wise) the PS1 behavior makes sense. The new PS0 behavior could not be combined with counting the columns, should we need that, because counting and non-counting characters can join up and together expand to something entirely different. Could you please modify the behavior to match that of PS1, as well as how PS0 was handled previously, just with the addition that you eliminate the final remaining 0x01 and 0x02 bytes at the _last_ step? (Honestly I don't know what happens if a variable expansion results in one of these bytes, I did not go down this rabbit hole that much.) --- In case you're wondering, here's our context: In VTE we set up PS0 to emit some escape sequences, of which the very last character that we need to print is a backslash. Users are complaining that if they append their own custom stuff to PS0 then our trailing backslash mangles that. It's a pretty unfortunate situation (surely with its own legacy compatibility story) that PSn undergoes different escaping depending on promptvars. In order to print 10 backslashes in a row, without promptvars the PSn variables have to contain 20 backslashes, with promptvars they have to contain 40. In order to print one backslash, without the possibility of leaking into and breaking the interpretation of anything the user appends to the prompt, we'd need 2 or 4 backslashes depending on promptvars. \[ \] (if they worked identically to how they do in PS1) would provide a convenient workaround for us: replacing the final backslash (which would no longer be final, it would precede the \]) with exactly 2 backslashes would always do the job properly. Yup, it's an accidental workaround – but I surely wouldn't ask bash to work around something for us if it weren't for bash itself also becoming more consistent with itself (including its documentation). Details: https://gitlab.gnome.org/GNOME/vte/-/work_items/2951 --- Thanks a lot, Egmont
