Date: Wed, 10 Jun 2026 19:20:41 +0900
From: Koichi Murase <[email protected]>
Message-ID:
<caflrlk9wuowpwr09mrz4d7hhvwovthcxuy2+amoucpnghob...@mail.gmail.com>
| A backslash in prompts is not stupid.
That's not what I said, I said it of the backslash expansions in prompts.
I doubt if any of the standards you listed (or any others) demand that the
sequence \w be converted into the process's current working directory (etc).
That was just David Korn copying what csh had done (csh had no variable
expansions in prompts, or certainly not in 1980 or before) because users
wanted expansions in prompts, he wanted to convert csh users to the much
better Bourne shell style, and he didn't think of doing it a more appropriate
way (then anyway). bash copied that, and now is stuck with the mistake
forever.
| 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 �.
You replied half way through the paragraph, it said inside "" or '' or $''
Which one you use depends upon the needs of the usage. "" is most useful
for expanding things like $(tput whatever) as it is rare that the output
from tput (for an unchanging "whatever", and without TERM altering) will
vary, and running a command substitution in every prompt for no reason is
just wasteful.
| 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.
If you can make things work with promptvars turned off, then you don't
need any variable expansions at all, and 99% of what you're complaining
about becomes nonsense.
| OK, so, do you suggest removing �shopt -u promptvars�? Yeah, if that
| will be accepted, that is ideal.
Yes, that would be better - but you know as well as I do it won't happen,
for backward compat reasons.
| We consistently want post-promptvars removal. I don't think there are
| cases where people want pre-promptvars removal.
Once again, there is no "removal" in bash, ever. Bash inserts the \1 and
\2 as replacements for \[ and \] when the string will be passed to readline.
It is readline that removes them, not bash. If there is no readline, there
is no removal at all, which is what the bug report which prompted the code
change you don't like was fixing (by not inserting the things into prompts
which won't be passed through readline).
| That shouldn't happen. A configuration for the magic adds significant
| complications and solves nothing. First of all, in the interactive
| shell settings, many independent settings are combined. If each
| setting wants to specify a distinct magic character to Bash/Readline,
| what would happen? Framework A sets \1\2 to Bash/Readline as the magic
| pair, and then framework B sets \3\4 to Bash/Readline, which breaks
| framework A.
No, none of that should happen, all that stuff should use \[ and \] (or
better var expansions which produce the same thing in the appropriate
context, and presumably nothing otherwise) and never care what the actual
interface to readline is. The user (for interactive use) based upon the
needs of whatever packages are in use picks a char (or pair of chars)
which will cause no problems for the packages in use, tells bash (by setting
a variable) what to use, and bash then uses that where the packages use \[.
| However, that's how Readline worked for PS1 from at least bash-1.14.7:
Yes, buried internal stuff that no-one is supposed to know about (unless
you're programming the shell or readline). It is when people start to
make use of this that we get problems, no-one should be aware of these
internal details.
| though I agree that they should actually be documented in the manual.
I'm not sure what you're agreeing with, as that isn't what I said. I said
they're not documented, the implication being that you cannot rely upon
them not changing. They should remain undocumented (as long as the
current approach remains, and the user doesn't get to pick what to use).
| Of course, that's absurd, because that is an example intentionally
| modified to be absurd.
Yes, of course.
| The situation is totally different.
No, just slightly different, and largely because you see no need for
a literal \1 or \2 to ever appear in a prompt, but you can see a use
for spaces (etc). That's the only difference, your limited imagination.
| I don't think whether we call it "remove" or "not insert" is relevant.
See above.
| So, you mean deleting \[\] shouldn't happen in PS0 and PS4? That is
| the behavior before commit 1e9f5e10 in the devel branch.
I have no idea what that commit refers do, I don't do git, and don't see
things like that. But are you sure it left \[ and \] in the strings,
so that if I were to do
PS1='\[ hello \] $'
then my prompt would be
\[ hello \] $
?
| We are talking about the timing of removing the markers.
Once again, the markers are never removed. They are passed to readline
in PS1 and PS2 and never inserted in PS0 or PS4 (and I have no idea about PS3).
| Let me clarify this for you: Before commit 1e9f5e10 (and in
| Bash 5.3):
|
| PS1 underwent (1) the \ processing, (2) the promptvars processing,
That's bash.
| (3) (layout calculations if necessary and) deletion of \1\2.
That's readline. Two separate things (even if a copy of readline does
come bundled with bash).
| 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:
|
| PS1: (1) (2) (3),
| PS0: (1) (2) (3).
You mean you wanted PS0 to be sent to readine? Why? What would it
be reading?
| However, after commit 1e9f5e10, the behavior became effectively
|
| PS1: (1) (2) (3),
| PS0: (1) (3) (2),
Only in your mind, it became (1) (2) which it always was, there was
a bug fixed which avoid sticking readline data into non readline strings.
| > I have promptvars set (since it is the default) and it works fine for me.
| So you were just lucky.
No, I know how to write a prompt string. In general they have no backslashes
in them at all, but if I were to need one, I can make it work.
| We are forced to care about such a situation because we provide
| settings to the users, where some users might turn off promptvars.
No you aren't, you simply tell them "promptvars must be on or this
won't work"
| Anyway, whether you personally care or not is irrelevant.
That's true.
| That's the opposite. We are talking about the behavior of PS0, which
| was introduced in Bash 4.4, where `shopt -u promptvars' were already
| present.
OK, I don't follow the timeline of what appeared when, and what is before
the other.
kre
