Date: Wed, 10 Jun 2026 07:07:43 +0900
From: Koichi Murase <[email protected]>
Message-ID:
<caflrlk-qrktyussq6hf1spdjpy75yx39qjbehq1bvzc65eo...@mail.gmail.com>
| No, that's not what we are trying to achieve. That is just an example
| to illustrate the impact of the recent change in commit 1e9f5e10.
OK.
| For the original background, you can reference the URL at the bottom
| of the original post.
That's weird, I have no idea what it is attempting to achieve, and no
desire to find out. But to me it looks as if the problems are caused
by attempts to use the (csh derived ultimately) totally stupid \ expansions
in prompts - those should be avoided completely, and ideally bash would
simply remove support for them all (except \[ and \], though even those can
be replaced) and because of those, if they remain, \\).
I know that won't happen because of backward compat issues, but the
right way to handle all of that is a combination of using $'...' to
handle the simple cases (\n \t ...) and variable expansions for all
the rest (creating new variables for the expansions which don't currently
have one) - expanded at assignment time (inside "") or at executing time
(inside '' or $'') and then just do the whole thing using var expansions (and
command substitutions, and occasionally arithmetic) in the prompt
definition (and the promptvars option should just go away and always
act as it does now when set).
There will always be issues when there are 2 different expansion
schemes happening at the same time (more or less) when one sometimes
wants one before the other, and other times the other order, it is
all just a giant mess.
| Yes, we agree that they should simply vanish. We are talking about the
| details of when they should vanish. Actually, the current behavior of
| the devel branch fails to properly remove \x01 and \x02 embedded in a
| command substitution, such as `$(prompt-framework git-status)'.
Why would bash be removing those chars? What if I want to send \1 or \2
to the terminal for some reason? Ideally it should be possible to
config (both bash & readline) to set what magic chars in the string are
the "no position changes from here" and "back to normal output" values,
so the user/script can set what ought to be used, rather than building
anything in. The the \[ and \] (or var espansions of vars which mean the
same thing) can simply get converted to those chars when it is appropriate,
and nothing in other cases.
The NetBSD shell has a PSlit var (libedit, a kind of readline lookalike)
uses 1 char as a toggle between "start non-movement mode" and "back to
normal mode" rather than 2 (one for start, and one for end) - that is an
immaterial difference, when set, the value of that var (its first char
anyway) is sent to libedit, and then prompts can use "${PSlit}" to turn
on (or off in our case) the non-movement mode. Given that kind of
ability, the shell doesn't need to do any processing of the prompt word
"${PS1}" (or whatever) beside parsing it like any other word in the shell,
and processing the normal in-word expansions over it (just the var
expansions (incl command subst and arith) of course no filename expansion
or field splitting) and then send that to libedit as the prompt to be
used whenever it requests one. It is really all very simple, very
painless to use, and very flexible (we have a whole bunch of vars which
expand to useful things to use in prompts, and of course users can use
their own vars, and set and change them whenever they want).
| 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. How would you feel if bash simply decided to
remove all \ chars, or spaces, or some other random character, just because
someone decided that if that was done, some trick that they had invented
would work? Totally absurd.
| We are talking about the detailed behavior of `what it should be
| doing'. Both removing \[\] from the beginning and removing \x01\0x02
| at the final step satisfy what you seem to request. You haven't
| explained why they should be removed before the `promptvars'
| processing instead of after `promptvars'.
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). Any
\[ \] in the string are simply deleted - and technically, perhaps even
that shouldn't happen, as PS0 and PS4 don't need such things.
| You seem to support
| pre-`promptvars' removal in the current devel branch, but it actually
| only removes the embedded markers halfway. To remove those markers,
| including the ones emitted by command substitutions of a prompt
| framework, one needs to remove them after `promptvars' instead of
| pre-`promptvars' removal.
As above, when the \ processing is done wrt when var expansions are done
can never be done in a way which satisfies all uses, do it one way and
some users won't be able to do what they want, do it the other way, and
other users won't be able to do what they want, try to do things multiple
times and no-one ends up happy, as nothing ever really works in a precdictable
way any more. "I want this var/cmd-subst expanded before \ expansions, as
I want to include \ expansions in its output, but this other var/.. expanded
after \ expansions as it is to contain \ chars that aren't to be expanded".
Nightmare.
As I understand it (and assuming that the absurd \ things are to remain in
prompt processing) bash has long documented the order in which those happen.
And that is, \ expansions first, var (etc) expansions second (if enabled).
If you cannot do what you want within those restrictions, then you need to
find a completely different way, as changing it will break someone else's
code.
| > a simple \ already does that.
| Unfortunately, no, when `shopt -s promptvars' is involved in Bash.
I have promptvars set (since it is the default) and it works fine for me.
If you mean it might not work the same without promptvars set (or in
ancient bash when there was no such thing) then I simply don't care.
kre
ps: from what I gather, part of the issue is the desire to support ancient
versions of bash, where promptvars didn't exist, and the \ expansions were
all that were available. I know that can be a problem, but sometimes when
people are stuck on ancient versions, you just need to tell them to upgrade
or things just won't work as expected.
