2026年6月11日(木) 4:11 Robert Elz <[email protected]>:
> | 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).
OK, that part was my misunderstanding.
> 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.
I agree, but the historical feature can't be canceled for backward
compatibility. In this thread, I'd like to discuss what we can do
within the restrictions.
> | 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 $''
You also quoted my reply halfway. The above part describes how it
doesn't work «inside ""». Then, the next paragraph in my reply, "That
doesn't work with «shopt -u promptvars». [...] to work with various
user configurations.", covers the case for «'' or $''».
> | 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,
As a matter of fact, it's not possible. E.g., achieving the behavior
of «PS4='+${BASH_SOURCE[0]}:$LINENO: '» is impossible without
`promptvars'. There are many cases. The original issue is one case.
> | 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.
Yes.
> | 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.
I already explained this in my previous reply. I wrote
>> "When the `expand_prompt' or `promptvars' processor sees \[\] or
>> \1\2 in the input, one doesn't insert anything in its output."
>> This is what I mean by `remove'. I'm sorry if I confused you, but
>> if you don't like the terminology `remove', could you please
>> replace `remove' with `not insert' when reading the above
>> arguments?
> | 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 \[.
I'm not exactly sure if I understand what you argue, but do you
possibly assume that frameworks A and B embed \1\2 or \3\4 directly
into PS1? No. Of course, I assume they use \[\]. The whole point that
you mentioned the needs of the configuration interface of the magic
character(s) is to make it possible to directly output \1\2 to the
terminal when someone wants to. Then, e.g., framework A specifies e.g.
\1\2 as the magic characters so that e.g. \3\4 can be sent to the
terminal, and later framework B rewrites the settings of the magic
number to \3\4 so that \1\2 can be sent to the terminal. Now, \3 and
\4, which framework A embedded in PS?, start to be interpreted
strangely and finally be stripped from the data that is finally sent
to the terminal.
> | 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.
Yeah, it's an issue that the user fails to send \1 or \2 when the user
sets \1\2 in PS?, but it's a longstanding problem separate from the
problem discussed in the present thread.
> | 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.
OK, I had to precisely state it this way: I agreed that it was a
problem that they are not documented in the manual. As a resolution of
the problem, we should document this. I unconsciously dropped the
possibility that you think it should remain undocumented. However, as
Chet has clarified in another reply, it's actually documented in
Readline's manual, though it might be a good idea to mention that also
in Bash's manual.
> 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).
The current approach of PS0 and PS4 allows embedding \1\2 to be sent
to the terminal, but the restriction is still present in PS1 and PS2.
One cannot send \1\2 as a part of control sequences through PS1. At
least, the restriction for PS1 and PS2 should be documented.
> | 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.
Whether it is a slight or total difference is subjective, so let me
avoid discussing the proper adjective. With your unlimited
imagination, could you tell me what would be the use case for the \1\2
(sent from the shell to the terminal), which doesn't have a typical
meaning for the terminal communication? I mentioned an RLogin example
in the original thread, but that's used to send a file and wouldn't be
something embedded in a protocol.
>>> 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.
>
> 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 \] $
>
> ?
No, no one is talking about such behavior. I meant that «deleting \[\]
doesn't happen and instead subsequent processing of inserting \1\2
instead». First, you mentioned «Any \[ \] in the string are simply
deleted ... even that shouldn't happen». Then, I thought you meant
«insert nothing instead of \1\2» by «delete \[\]», and I thought that
you suggested keeping \1\2 inside the resulting string by «that
(deleting \[\]) shouldn't happen».
> | 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).
As I mentioned in the previous reply,
>> if you don't like the terminology `remove', could you please
>> replace `remove' with `not insert' when reading the above
>> arguments?
I start to suspect that you intentionally misunderstand the arguments
in absurd ways or intentionally stick to the terminology to avoid the
direct discussion.
> | 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).
I don't think that whether the entire processing is implemented in
Bash or Readline is important in the design of the behavior. Bash
calls Readline's (3) to perform the additional processing for PS1 and
PS2 when line editing is enabled. Then, what is an issue with
performing another processing when line editing is not involved?
> | 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?
No. I'm not talking about the behavior but not an implementation. I
wrote "(layout calculations *if necessary* and)" in the above (3)
explanation, which means that we send the string to Readline if
necessary, or otherwise we can simply remove \1\2 from the string.
> | 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.
No, it was "PS0: (1) (2)" [meaning that \1\2 were inserted and
remained in the input to (2)] before the change, but now it becomes
"PS0: (1) (3) (2)", where (3) means the *behavior of not inserting
\1\2* [I'm talking about the behavior in the outcome but not how the
actual implementation realizes that]. Here, (3) does not mean "sending
the string to Readline".
> | > 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.
OK, so you can make it work assuming `promptvars'. I just wanted to
tell that `simple \' that you mentioned is not quite true when
`promptvars' is turned on.
> | 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"
OK, yes. Technically, there is no authority forcing us to support an
arbitrary set of options.
We just want to support a wider range of options, and it can be
achieved by simply adjusting the devel change in commit 1e9f5e10. In
addition to that, even without thinking of the original discussion of
the OSC sequence with/without `promptvars', I believe the *behavior*
"PS0: (1) (2) (3)" is more understandable than the *behavior* "PS0:
(1) (3) (2)" [Again, I'm not talking about the internal implementation
of e.g. whether Readline is used or not, but the *behavior* visible to
the users], considering the typical behavior of PS1 (with line editing
enabled). So, I wrote «could you take this as ``a feature request''
for another consistent behavior?».
--
Koichi
