2026年6月12日(金) 5:43 Chet Ramey <[email protected]>: > On 6/10/26 6:20 AM, Koichi Murase wrote: > >> variable expansions for all the rest (creating new variables for the > >> expansions which don't currently have one) - expanded at assignment > >> time (inside "") > > > > That doesn't work because a backslash at the end of the value of the > > variable will escape the next character unexpectedly. > > > > bs='\' > > PS0="${bs}w " > > > > Then you'll get «<current working directory> » instead of «\w ». > > Because you used double quotes in the assignment, assigning the string > "\w" to PS0. If you had used single quotes, the ${bs} would have been > expanded after the backslash-escape sequences, and you'd see `\w ' > displayed.
Yes. That's what I wanted to explain. > > 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, which I believe is more consistent with the traditional behavior of PS0 and PS4 and also consistent with the PS1 (when the line editing is enabled). So, this is a request for the change of the behavior. > > I totally agree, but we can't redesign this for backward > > compatibility. Adding even another option to unify those expansions to > > a single-pass conversion is even worse. > > > >> when one sometimes wants one before the other, and other times the > >> other order, it is all just a giant mess. > > > > We consistently want post-promptvars removal. I don't think there are > > cases where people want pre-promptvars removal. > > 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. We are not requesting to preserve \1\2 not originating from \[\] in the output. > > Because they are internally used for the markers of \[ and \]. I don't > > know the reason that the markers are not embedded in a transparent > > way, such that raw \1 and \2 are preserved by an escaping mechanism. > > \1 and \2 are documented by readline as the way for applications to signal > which characters in the prompt string are and are not visible for > redisplay. Readline is used by dozens of other applications, some of which > support their own mechanisms for using them. They are not bash-specific. OK. Actually, when replying to kre's original argument, I actually thought there was something in Readline's documentation, but I couldn't find it. > >> The issue is that, as I understand things, they aren't being removed at > >> all - they simply are no longer being inserted where they once were, as > >> they are not needed in PS0 or PS4 (in them, nothing there cares what chars > >> in the string use char positions on the terminal, and which don't). > > > > I don't think whether we call it "remove" or "not insert" is relevant. > > They are equivalent. > > Obviously not. You want them inserted, then removed later, so they exist in > the prompt string for long enough to act as dummy separators. > > > >> Any \[ \] in the string are simply deleted - and technically, > >> perhaps even that shouldn't happen, as PS0 and PS4 don't need such > >> things. > > > > So, you mean deleting \[\] shouldn't happen in PS0 and PS4? That is > > the behavior before commit 1e9f5e10 in the devel branch. > > That is not what he said, and not what used to happen. The behavior of bash > before the above commit was to replace \[ and \] with 0x01 and 0x02, > respectively, when expanding PS0 and PS4. In the above argument, I was considering the two cases between «deleting \[\] (i.e., inserting nothing to the output of backslash processing)» and «inserting \1\2». (Or in other words, if \[\] are not deleted, they then undergo the normal conversion to \1\2). That is, I meant «inserting \1\2 is the behavior before commit 1e9f5e10 in the devel branch». > Let me clarify this for you: Before commit 1e9f5e10 (and in > > Bash 5.3): > > > > PS1 underwent (1) the \ processing, (2) the promptvars processing, > > (3) (layout calculations if necessary and) deletion of \1\2. > > Sigh. 0x01 and 0x02 remain in the prompt string, even when it's passed to > readline. Readline performs its own interpretation of those markers, which > effectively means that it doesn't use them in redisplay calculations or > write them to the terminal. Bash is out of the picture. In the above explanation, «deletion of \1\2» means that «Readline does not write them to the terminal». > > PS0 underwent (1) the \ processing, (2) the promptvars processing. > > > > We requested to add to PS0 a transform that is equivalent to (3), > > i.e., expecting something like this: > > The original request asked for 0x01 and 0x02 not to appear in PS0. Right, that part of the request was satisfied by the change in commit 1e9f5e10. However, the request was not explicit about how the effect should or should not interfere with the `promptvars' expansions. > Subsequent messages clarified that you want 0x01 and 0x02 to act as dummy > separator characters, and new code that goes through the decoded prompt > string and removes occurrences of 0x01 and 0x02 (but not when it's PS1 or > PS2!). > > > > > PS1: (1) (2) (3), > > PS0: (1) (2) (3). > > > > However, after commit 1e9f5e10, the behavior became effectively > > > > PS1: (1) (2) (3), > > PS0: (1) (3) (2), > > > > though, in the actual implementation, (1)+(3) is effectively combined > > to directly produce the (1)+(3) result). In this thread, we are > > requesting to correct (1) (3) (2) to (1) (2) (3) to match PS0's > > You say that like it's an error to correct. > > It's not. You want a way to separate arbitrary portions of the prompt > string (or the final portion of the supplied PS0 and what the user > might want to append, at least). That's the ask here. The motivation of the original request that introduced the devel change 1e9f5e10 has been that «if \[\] in PS0 works like the ones in PS1 (i.e., \1\2 are not written to the terminal), \[\] can be used as a trick». I can agree that that was just "a trick" and not an intended usage of \[\]. 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. Actually, maybe we should now request reverting the \[\] change in 1e9f5e10. No one desired the behavior of the current devel change in 1e9f5e10, and it simply interferes how `promptvars' is applied to PS0 and PS4, which breaks a compatibility issue. > > behavior to PS1's behavior because that creates a difference between > > PS1 and PS0 for how promptvars is applied to an identical setting. > > Why would you force PS1 and PS0 to behave identically, when one is passed > to readline and one is not? They serve different purposes and have > different requirements. 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? -- Koichi
