Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue
On 11/25/19 10:05 AM, Алексей Шилин wrote:
Bash Version: 5.0
Patch Level: 11
Release Status: release
Description:
I'm using the following PS1 prompt (Debian's default for normal users):
\[\e]0;\u@\h:
\w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\
]:\[\033[01;34m\]\w\[\033[00m\]\$
...where the first block '\[\e]0;\u@\h: \w\a\]' is for setting xterm's
title, and the rest is Debian's "fancy" shell prompt.
Is there a literal newline in the prompt string? And is it in the middle
of the non-printing character block?
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue
On Wed, Nov 27, 2019 at 11:02:49AM -0500, Chet Ramey wrote:
> On 11/25/19 10:05 AM, Алексей Шилин wrote:
> > I'm using the following PS1 prompt (Debian's default for normal users):
> >
> > \[\e]0;\u@\h:
> > \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\
> > ]:\[\033[01;34m\]\w\[\033[00m\]\$
> >
> > ...where the first block '\[\e]0;\u@\h: \w\a\]' is for setting xterm's
> > title, and the rest is Debian's "fancy" shell prompt.
>
> Is there a literal newline in the prompt string? And is it in the middle
> of the non-printing character block?
No, at least not in Debian's configuration files. It's most likely an
artifact of their mail user agent.
Debian's /etc/skel/.bashrc contains these lines:
if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
'
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
The leading \[\e]0... part appears to be a local addition.
Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue
В Ср, 27/11/2019 в 11:02 -0500, Chet Ramey пишет:
> On 11/25/19 10:05 AM, Алексей Шилин wrote:
>
> > Bash Version: 5.0
> > Patch Level: 11
> > Release Status: release
> >
> > Description:
> >
> > I'm using the following PS1 prompt (Debian's default for normal
> > users):
> >
> > \[\e]0;\u@\h:
> > \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[
> > 00m\
> > ]:\[\033[01;34m\]\w\[\033[00m\]\$
> >
> > ...where the first block '\[\e]0;\u@\h: \w\a\]' is for setting
> > xterm's
> > title, and the rest is Debian's "fancy" shell prompt.
>
> Is there a literal newline in the prompt string? And is it in the
> middle
> of the non-printing character block?
>
No, of course not. It's Evolution doing its thing, splitting the line.
Sorry for the confusion.
Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue
On 11/27/19 11:24 AM, Алексей Шилин wrote:
В Ср, 27/11/2019 в 11:02 -0500, Chet Ramey пишет:
On 11/25/19 10:05 AM, Алексей Шилин wrote:
Bash Version: 5.0
Patch Level: 11
Release Status: release
Description:
I'm using the following PS1 prompt (Debian's default for normal
users):
\[\e]0;\u@\h:
\w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[
00m\
]:\[\033[01;34m\]\w\[\033[00m\]\$
...where the first block '\[\e]0;\u@\h: \w\a\]' is for setting
xterm's
title, and the rest is Debian's "fancy" shell prompt.
Is there a literal newline in the prompt string? And is it in the
middle
of the non-printing character block?
No, of course not. It's Evolution doing its thing, splitting the line.
Sorry for the confusion.
OK. The reason I ask is that I can (unsurprisingly) reproduce multiple
redisplay issues if the newline after the `\h:' is present, but none
when $PS1 doesn't contain any newlines.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue
> Debian's /etc/skel/.bashrc contains these lines:
>
> if [ "$color_prompt" = yes ]; then
>
> PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m
> \]:\[\033[01;34m\]\w\[\033[00m\]\$
> '
> else
> PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
> fi
>
> The leading \[\e]0... part appears to be a local addition.
>
It's there, a few lines below. See
https://sources.debian.org/src/bash/5.0-5/debian/skel.bashrc/#L69
Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue
В Ср, 27/11/2019 в 11:48 -0500, Chet Ramey пишет: > The reason I ask is that I can (unsurprisingly) reproduce multiple > redisplay issues if the newline after the `\h:' is present, but none > when $PS1 doesn't contain any newlines. You mean you can't reproduce the issue? That's weird, since I can easily do it in Konsole, in GNOME Terminal, even in bare tty; in Debian 10, in Fedora 31 - all with PS1 as simple as '\[\e]0;\w\a\]\w\$ '. Are you sure you're using a multi-byte path (like the one I provided) and a *.UTF-8 locale?
Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue
On 11/27/19 3:19 PM, Алексей Шилин wrote: > В Ср, 27/11/2019 в 11:48 -0500, Chet Ramey пишет: >> The reason I ask is that I can (unsurprisingly) reproduce multiple >> redisplay issues if the newline after the `\h:' is present, but none >> when $PS1 doesn't contain any newlines. > > You mean you can't reproduce the issue? That's weird, since I can > easily do it in Konsole, in GNOME Terminal, even in bare tty; in Debian > 10, in Fedora 31 - all with PS1 as simple as '\[\e]0;\w\a\]\w\$ '. Are > you sure you're using a multi-byte path (like the one I provided) and a > *.UTF-8 locale? Yes, and yes. I poked around enough and found the cause. There will be a fix in the next devel branch push. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue
В Ср, 27/11/2019 в 20:29 -0500, Chet Ramey пишет: > I poked around enough and found the cause. There will be a > fix in the next devel branch push. That's awesome! Thank you *very* much!
