Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing
On Thu, 2023-09-21 at 23:31 +0200, Egmont Koblinger wrote: > VTE's emulation behavior didn't change recently. Bash/Readline could > have changed, I don't know (might be interesting to check their > Ubuntu > packages' changelogs). What I did notice that libvte and gnome-terminal packages were both updated recently, and I think I gnome-terminal packages were only updated a few days after. But that still doesn't explain, why it suddenly happened with the old libvte packages. > Or you're executing somewhat different steps. > > If the printed prompt is exactly the same (including all the bells > and > whistles that it prints, like the username, hostname, working > directory, previous command's exit value, background job stuff), and > the terminal width is exactly the same (is it?), and you're pressing > the same keys to invoke the same previous commands or editing the > current command in the exact same way, then you should see the exact > same behavior. Any difference in any of these could make the bug > appear or vanish. At least I wouldn't be aware of doing anything differently. > Also make sure that the previous command's output ended with a > newline, that is, the prompt begins in the first column. Otherwise > it's common to see misbehavior while editing. That's clear, and that was definitely not the case. > By now we are sure that we're talking about two separate issues. The > line editing misbehavior is surely independent from Samuel's patch. I guess so, too. Thanks, Chris.
Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing
Christoph Anton Mitterer, le jeu. 21 sept. 2023 22:56:31 +0200, a ecrit: > It's a bit weird, I can *no* longer reproduce it. I can't either, be it with or without my patches. Samuel
Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing
Hi, > It's a bit weird, I can *no* longer reproduce it. VTE's emulation behavior didn't change recently. Bash/Readline could have changed, I don't know (might be interesting to check their Ubuntu packages' changelogs). Or you're executing somewhat different steps. If the printed prompt is exactly the same (including all the bells and whistles that it prints, like the username, hostname, working directory, previous command's exit value, background job stuff), and the terminal width is exactly the same (is it?), and you're pressing the same keys to invoke the same previous commands or editing the current command in the exact same way, then you should see the exact same behavior. Any difference in any of these could make the bug appear or vanish. Also make sure that the previous command's output ended with a newline, that is, the prompt begins in the first column. Otherwise it's common to see misbehavior while editing. > @Samuel, could you please also try whether you can still reproduce it? > If not, I'd say we might close the issue. By now we are sure that we're talking about two separate issues. The line editing misbehavior is surely independent from Samuel's patch. You casually mentioned that you saw a crash, that one is probably caused by that patch, but there's no stack trace here, and we already have two other bugreports that focus on that crash and contain way more information. > That's interesting... why do you think so? The command substitution > should also be bash, and I'd have thus expected \[ and \] inside it > have therefore the same representation as outside and should thus be > identical? Vague memories from things I saw multiple times, maybe in bash's doc, maybe on forums, I can't recall. I might be wrong. Actually, I might mistake it with the prompt string you pass to readline if you're programming against that library. In that case your prompt looks good to me. Sorry, it's too late here and I'm too tired to look it up or investigate right now. cheers, e.
Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing
Hey there. It's a bit weird, I can *no* longer reproduce it. I have now (and everything else except libheif* at the current versions of unstable): libvte-2.91-0:amd64 0.74.0-2 gnome-terminal 3.50.0-1 If I use my original PS1 and the command I've mentioned before, go back with the Up key and then remove the "2"... everything seems fine. @Samuel, could you please also try whether you can still reproduce it? If not, I'd say we might close the issue. @Egmont, sorry, I hadn't seen you reply to the bug (Deb BTS is... well...). I now tried with xterm (where the issue doesn't appear, but as I've said, I cannot even reproduce it with gnome-terminal anymore. > In fact, I _think_ the culprit is that inside command substitution > stuff, a.k.a.. $(...), nonprintable characters need to be enclosed > within the raw bytes 0x01 and 0x02, rather than the two-character > sequences \[ and \]. Not entirely sure, though. That's interesting... why do you think so? The command substitution should also be bash, and I'd have thus expected \[ and \] inside it have therefore the same representation as outside and should thus be identical? Cheers, Chris.
Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing
Christoph Anton Mitterer, le mar. 19 sept. 2023 14:23:47 +0200, a ecrit: > On Tue, 2023-09-19 at 13:47 +0200, Samuel Thibault wrote: > > I can't reproduce it. > > Interestingly, I've just been able to reproduce it even with 0.73.99-1: This is reproducible also with 0.74.0-2, which has my patches reverted, I also tried 0.73.99-1 with the first of my patches reverted. So the swallow bug is not related to my patches. Samuel
Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing
Christoph Anton Mitterer, le mar. 19 sept. 2023 14:23:47 +0200, a ecrit:
> > Random difference guesses:
> >
> > - Does it happen with a plain
> >
> > PS1="$ "
> >
> > prompt?
>
> It does indeed not happen with that prompt string.
Ok, so the prompt does matter.
> My PS1 is a bit more complex, but has worked so far:
> $ printf '%s\n' "$PS1"
> \[\e[0m\]\[\e[32m\]\u\[\e[0m\]\[\e[2;37m\]@\[\e[0m\]\[\e[32m\]\h\[\e[0m\]\[\e[2;37m\]:\[\e[0m\]\[\e[1;34m\]\w\[\e[0m\]$(
> [ "$?" -eq 0 ] && { [ -n "$(jobs -s; jobs -r)" ] && printf
> '%s{%s%s\j%s%s}%s' '\[\e[2;37m\]' '\[\e[0m\]' '\[\e[36m\]' '\[\e[0m\]'
> '\[\e[2;37m\]' '\[\e[0m\]'; true; } || { [ -n "$(jobs -s; jobs -r)" ] &&
> printf '%s{%s%s\j%s%s}%s' '\[\e[2;37m\]' '\[\e[0m\]' '\[\e[36m\]' '\[\e[0m\]'
> '\[\e[2;37m\]' '\[\e[0m\]'; false; } )$( [ "$?" -eq 0 ] && printf '%s'
> '\[\e[2;37m\]' || printf '%s' '\[\e[31m\]' )\$\[\e[0m\]\[\e]0;\u@\h:\w\e\\\]
Ok, with that PS1 it seems I can reproduce it.
I also notice that there is a bug as soon as pressing the up arrow: the
trailing ] gets dropped. If I press ^L after pressing the up arrow,
dropping the 2 doesn't eat the > along. So possibly it's actually the up
arrow output which is bogus, and the > eat is just a consequence. I'll
dig a bit.
> > - Is your terminal using TERM=xterm-256color or something else?
> TERM is xterm-256color
Ok.
> > - Does it happen with a reinitialized profile?
> What do you mean? Fresh .profile and friends?
I just meant the gnome-terminal profile. But since I can reproduce with
my current setting, it should be all good.
Samuel
Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing
Hi Chris, > Interestingly, I've just been able to reproduce it even with 0.73.99-1: This makes sense. I was wondering how a patch that supposedly only touches a11y (how the contents are read out loud) could have an effect on the actual emulation behavior. Can you try under xterm or other non-VTE-based terminals? I suspect you'll see the same behavior there. It could be a bash issue, or a misconfigured prompt. In fact, I _think_ the culprit is that inside command substitution stuff, a.k.a.. $(...), nonprintable characters need to be enclosed within the raw bytes 0x01 and 0x02, rather than the two-character sequences \[ and \]. Not entirely sure, though. If you can't locate the problem, and if it's specific to VTE, then you should record the traffic using `script` and it should be manually, step-by-step verified what the terminal does for that, e.g. compared against xterm to see where it goes different. But I'm almost entirely certain that it'll be a bash issue rather than a VTE one. Nevertheless, the crash you encountered might be the same caused by the currently debated a11y patch. e.
Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing
On Tue, 2023-09-19 at 13:47 +0200, Samuel Thibault wrote:
> I can't reproduce it.
Interestingly, I've just been able to reproduce it even with 0.73.99-1:
I have this command:
$ exiftool -p '${CreateDate} ${FileName}' * 2> /dev/null
press enter, then Up key, then I move the cursor behind the 2 and
backspace delete it.
This removes not only the two, but als the >, so I now see:
$ exiftool -p '${CreateDate} ${FileName}' * /dev/null
> Does it happen at all editing positions?
>From cherry picking a few: yes
> Random difference guesses:
>
> - Does it happen with a plain
>
> PS1="$ "
>
> prompt?
It does indeed not happen with that prompt string.
My PS1 is a bit more complex, but has worked so far:
$ printf '%s\n' "$PS1"
\[\e[0m\]\[\e[32m\]\u\[\e[0m\]\[\e[2;37m\]@\[\e[0m\]\[\e[32m\]\h\[\e[0m\]\[\e[2;37m\]:\[\e[0m\]\[\e[1;34m\]\w\[\e[0m\]$(
[ "$?" -eq 0 ] && { [ -n "$(jobs -s; jobs -r)" ] && printf '%s{%s%s\j%s%s}%s'
'\[\e[2;37m\]' '\[\e[0m\]' '\[\e[36m\]' '\[\e[0m\]' '\[\e[2;37m\]' '\[\e[0m\]';
true; } || { [ -n "$(jobs -s; jobs -r)" ] && printf '%s{%s%s\j%s%s}%s'
'\[\e[2;37m\]' '\[\e[0m\]' '\[\e[36m\]' '\[\e[0m\]' '\[\e[2;37m\]' '\[\e[0m\]';
false; } )$( [ "$?" -eq 0 ] && printf '%s' '\[\e[2;37m\]' || printf '%s'
'\[\e[31m\]' )\$\[\e[0m\]\[\e]0;\u@\h:\w\e\\\]
(yes I know this might be simplified,... but it's generated from some
options)
> - Is your terminal using TERM=xterm-256color or something else?
TERM is xterm-256color
> - Does it happen with a reinitialized profile?
What do you mean? Fresh .profile and friends?
Cheers,
Chris.
Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing
On Tue, Sep 19, 2023 at 7:45 AM Egmont Koblinger wrote: > Jeremy, I recommend you to revert that patch and hold it off until it > gets fixed and receives a fair amount of testing. Well, this was one way to get some testing :) But yes, I am removing the patch from Debian Unstable now. Thank you, Jeremy Bícha
Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing
Hello, Christoph Anton Mitterer, le mar. 19 sept. 2023 01:11:53 +0200, a ecrit: > What I do is, getting a line from the history, either via the Up-key > or via incremental reverse searh (Ctrl-R) and when I then edit this > line (e.g. remove a character), another character is wrongly swallowed, > as if the escape sequences wouldn't work properly. I can't reproduce it. Does it happen at all editing positions? Does it happen at the first removal? Does it happen at insertions? Random difference guesses: - Does it happen with a plain PS1="$ " prompt? - Is your terminal using TERM=xterm-256color or something else? - Does it happen with a reinitialized profile? Samuel
Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing
Hi, It's apparently the same as Debian bug #1052172, caused by Debian backporting an untested patch that just made it to upstream's development branch and apparently hasn't received proper testing. Upstream discussion begins at https://gitlab.gnome.org/GNOME/vte/-/issues/88#note_1849187 . Jeremy, I recommend you to revert that patch and hold it off until it gets fixed and receives a fair amount of testing. cheers, e.
Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing
Package: libvte-2.91-0 Version: 0.74.0-1 Severity: important Hey. After upgrading to 0.74.0-1 I've experienced some weired behaviour when editing history lines in bash (via libreadline). What I do is, getting a line from the history, either via the Up-key or via incremental reverse searh (Ctrl-R) and when I then edit this line (e.g. remove a character), another character is wrongly swallowed, as if the escape sequences wouldn't work properly. I should mention that in .inputrc I have: set mark-modified-lines On Downgrading to 0.73.99-1 fixes the issue. Also, but possibly unrelated to this, I've just somehow manged to cause a segfault: [Sep19 01:01] gnome-terminal-[5265]: segfault at 565171bb7000 ip 7fcfeb6ecb30 sp 7ffd1f173b38 error 4 in libglib-2.0.so.0.7800.0[7fcfeb679000+99000] likely on CPU 2 (core 4, socket 0) [ +0,12] Code: 00 00 00 48 39 fe 72 0b eb 40 48 89 f8 48 89 f7 48 89 c6 48 f7 da 48 39 f7 72 ef 31 c0 4c 8d 05 76 0f 06 00 48 39 fe 73 38 90 <0f> b6 0e 48 83 c0 01 49 0f be 0c 08 48 01 ce 48 39 fe 72 ec 48 0f Not really sure what I did... I think I did some touchpad scrolling when either the terminal or the Cinnamon window list item for the terminal had the focus. Thanks, Chris. Below information is when libvte-2.91-* were already downgraded: -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libvte-2.91-0 depends on: ii libatk1.0-0 2.49.91-2 ii libc62.37-10 ii libcairo-gobject21.17.8-3 ii libcairo21.17.8-3 ii libfribidi0 1.0.13-3 ii libgcc-s113.2.0-4 ii libglib2.0-0 2.78.0-2 ii libgnutls30 3.8.1-4+b1 ii libgtk-3-0 3.24.38-5 ii libicu72 72.1-3 ii libpango-1.0-0 1.51.0+ds-2 ii libpangocairo-1.0-0 1.51.0+ds-2 ii libpcre2-8-0 10.42-4 ii libstdc++6 13.2.0-4 ii libsystemd0 254.3-1 ii libvte-2.91-common 0.73.99-1 ii zlib1g 1:1.2.13.dfsg-3 libvte-2.91-0 recommends no packages. libvte-2.91-0 suggests no packages. -- no debconf information
