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.
