> The solution to that is trivial, since it is "your users" who will be > using this thing, which I take to mean users of the vte terminal emulator.
Normally, yes. However, occasionally users of other terminals might also use this PS0 (if they launch another terminal from a vte-based one). Therefore, ideally, we'd look for a solution that robustly works in all terminals. Rather than having to send some internal marker to the terminal and rely on the terminal ignoring that, the proper approach would be to only send to the terminal what we actually want to send. If we're fine with a vte-only solution and we expect vte to ignore certain bytes then bytes 0x01 or 0x02 (which \[ and \] map to) were already fine before the recent change. Anything before vs. after these bytes were kept separated all along the process. However, the recent change broke this. By eliminating them too early, i.e. before the promptvars expansion rather than after, it's possible for data to spill over across this boundary. That is, the fresh new behavior is not in any aspect better for us, but in a certain aspect (if we relied on the terminal ignoring the 0x01 / 0x02 markers) it is actually worse, the use of \[ \] in PS0 (which would end up as 0x01 0x02 bytes ignored by the terminal) is no longer a possible workaround for us to consider. > Simply append some character that vte will do nothing with > when it receives it As per above, it's not necessarily just vte. And there's no escape sequence I'm aware of that is documentedly a no-op. > what do you do with a received \6 (ascii ack) ? We (vte) don't do anything. Other terminals might, e.g. Zutty prints a replacement symbol (just as it does for \1 or \2). But even if it was a no-op in all the terminals, it wouldn't justify its semantical misuse. > I'd suggest a zero-width space character, if you do anything other than > ignoring one of those when received, I'd be surprised. We do remember it as a combining accent and carry it if the data is copy-pasted. Similarly, searching the buffers for the sequence of the preceding and the subsequent character right next to each other (without that intermediate zero-width space) won't find that match. One day if we'll have ligature support then it might even affect rendering. Plus, we need a solution that works with legacy charsets too. > if you want to be able to work without the > promotvars option enabled, which I wouldn't bother with, then you need to > also find a solution which requires no variable expansions (etc) at output > time. This made me realize that we indeed do already rely on promptvars elsewhere (in PS1's value). If vte's main dev agrees with me, we'll probably set it in stone to require 'promptvars'. This, in turn, if I understand correctly, makes 4 backslashes in PSn reliably end up as 1 backslash getting printed, without any possibility of spillover if the user appends something to PSn. (It'll break if the user decides to disable promptvars though.) Probably the best compromise we can have. Using Koichi's numbering, prompt strings were typically processed through steps (1) (2) (3), but sometimes only through (1) (2). We asked to unify the situation. Instead, the latter case was modified to process it through steps (1) (3) (2). We followed up with the request of turning the latter to the same sequence of (1) (2) (3), pointing out weird inconsistencies resulting from the wrong order. This followup request of ours was met with a resistance we absolutely do not understand. The new order of (1) (3) (2) is not in any way better for us than the old order of (1) (2), in fact, in some aspect it's even worse. If you guys are reluctant to print the same prompt in the readline vs. noediting cases then you might even consider reverting the recent half-baked workaround, it's of no use for us, we'll need to find a different way of navigating through all the possible different behaviors of bash. e. On Fri, Jun 12, 2026 at 10:35 AM Egmont Koblinger <[email protected]> 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. > > 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. > > > It seems to me that you have an extremely bottom-up approach. You know the > building blocks of bash, including readline or lack thereof, and given the > way these buliding blocks are connected up together, the variance of the > final result surely does make a lot of sense. That is, to anyone who's > familiar with bash's internal architecture and cares about it; which, let's > be honest, probably isn't the majority of bash's users. > > 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. > > 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 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. > > 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). > > > > 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. > > > > 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. > > Or, as per your recent commit, address them at a different place, resulting > in inconsistent overall behavior in the editing vs. noediting cases. > > 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. 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. > > This way the end result is "consistent" (according to the top-down view: > toggling a flag doesn't affect the printed string), the documentation is the > simplest possible, and even PS1-PS2 won't fundamentally change when flipping > 'noediting'. That's what I'd call "consistent". > > > e. >
