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.
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.
(and the promptvars option should just go away and always act as it does now when set).OK, so, do you suggest removing «shopt -u promptvars»? Yeah, if that will be accepted, that is ideal.
Come on.
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.
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.
It's just for historical reasons, and we can't switch the behavior now.What if I want to send \1 or \2 to the terminal for some reason?There is no way. However, PS1 worked this way for a long time, and it hasn't caused an issue because most terminals just ignore \1 and \2.
Most do, some don't. That was the substance of the original report: "In turn, most modern terminal emulators that I'm aware of ignore these bytes. An exception I've found is Zutty, it prints replacement symbols, causing unexpected visual result. I'm pretty sure there are other software and hardware terminals as well where this can cause problems."
| To remove \x01 and \x02 properly, they should be removed at the very last | step, as we are requesting in the present thread. Those shouldn't be removed at all, I see nothing in the bash doc that says they are special.However, that's how Readline worked for PS1 from at least bash-1.14.7: bash-1.14.7$ grep -rn '#define RL_PROMPT_' lib/readline/readline.h:282:#define RL_PROMPT_START_IGNORE '\001' lib/readline/readline.h:283:#define RL_PROMPT_END_IGNORE '\002' though I agree that they should actually be documented in the manual.
They are documented as part of the readline documentation; this is a
readline feature.
"Applications may indicate that the prompt contains characters that take
up no physical screen space when displayed by bracketing a sequence of
such characters with the special markers @code{RL_PROMPT_START_IGNORE}
and @code{RL_PROMPT_END_IGNORE} (declared in @file{readline.h} as
@samp{\001} and @samp{\002}, respectively).
This may be used to embed terminal-specific escape sequences in prompts.
If you don't use these indicators, redisplay will likely produce screen
contents that don't match the line buffer."
The characters \1 and \2, which are effectively no-op in terminals, are different from graphical characters and control characters associated with functions in terminals.
They're not always, see above. But if they are, at least to a degree with which you're comfortable, there's nothing stopping you from using them yourself.
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. 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.
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. 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 issue of having two passes that both process a backslash quoting a backslash (the "if we want 10 backslashes we have to put up to 40 in the prompt string" depending on the `promptvars' setting from a follow-up message) isn't really the problem. That doesn't affect anything unless the user wants to append to PS0. The problem is having a dummy invisible character to separate the final backslash from whatever the user might want to add. You could, in fact, add such a dummy character yourself -- it could even be 0x02, since that doesn't affect most terminals, you assert above, and it's not going to affect cursor positioning.
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.
--
``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
