On 6/12/26 4:35 AM, Egmont Koblinger wrote:
Hello,(Sorry for the delay, I was away for a few days.) > Try it with --noediting; the same thing happens. > > The current devel behavior is consistent:So far I've only discovered the 'promptvars' circumstance that makes the string being interpreted differently.Now it turns out '--noediting' also does. Indeed, as you say, toggling `-- noediting` can drastically change the way PS1 ends up being displayed.And you call it "consistent". Well, I don't.
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.
As someone who wants to create a pre-set PS0 for our users, it already means I need to develop and test the value against at least 4 possible different setups.
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. You want a dummy separator character sequence. You should be able to supply one.
I'm more of a top-down guy. I believe I shouldn't need to care about the internals. I expect to have clearly documented quoting characters which end up doing the same thing, no matter which mode of operation is in effect.
Then you're advocating for a documentation fix, since, as we both note, the \[ and \] escapes never worked in the way you assumed for PS1 and PS2.
A couple of years ago I implemented setting up PS0, PS1 and PS2 in a consistent way in vte.sh, in a way that they together set up "shell integration" for the terminal to know (via escape sequences) where the shell prompts are. Whlie doing so, I already had the knowledge that unprintable characters of PS1 and PS2 need to be enclosed in \[ \]. For consistency, I did the same for PS0, too. I knew it did't go through readline, which made a bit suspicious that \[ \] may not "work" identically here, but I even checked the documentation which said they're "supported".
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. You want a new feature. Fine. Let's evaluate it as a new feature.
And then I checked the behavior: they weren't eliminated; for the proper behavior I had to omit the \[ \] markers from PS0. Back then my intent to report this inconsistency fell through the cracks.
Frankly, we would probably have had the same discussion back then. Your assumption about `proper' is just that: an assumption. You might well have used `desired'.
By "work" and "supported", put in double quotes in the previous paragraph, again I guess we again mean different things. Your bottom-up approach probably says they work the way they should, it's just different of what their role is in PS1. With my top-down approach I say they don't work as expected (and definitely not as documented).
I say it makes no sense to insert characters just to remove them later so you can have a dummy separator following a trailing backslash.
> if the prompt string is passed to > readline, the \[ and \] are converted to readline markers; if the prompt is > not passed to readline, they are ignored.Ignored at a different step than readline would handle them. Readline handles them _after_ the `promptvars` substitutions. Your recent patch makes the non-readline case remove them _before_ that step.
In PS0 and PS4. They were always ignored at that point in PS1 and PS2.
> Maybe a simple admonishment in the man page will be sufficient.Surely one possible way to address the inconsistency is to document that the \[ \] markers have undesireable side effects (or rather, just say: aren't supported) in PS0.
Yes.
Or, as per your recent commit, address them at a different place, resulting in inconsistent overall behavior in the editing vs. noediting cases.
But that's the issue: the patch makes the non-readline cases consistent across the various prompt strings.
My generic experiences (not related to bash's internals) tell me that these wouldn't be the cleanest solutions. In my opinion, the cleanest solution (regarding the final behavior, as well as regarding the documentation, as well as regarding internal architectural cleanness) would be to address them at corresponding, parallel locations.
Sure, you want a new feature.
Whenever you make the decision whether to pass the string to readline or to just print it, that is the exact place where you'd bring in the knowledge that readline would eliminate 0x01 and 0x02, therefore you also manually eliminate them in the other (noediting) branch, just before printing them.
You'd have to keep track of which instances resulted from \[ and \] and
only remove those, of course. Perhaps not as straightforward as you might
think.
--
``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
