On Sun, Nov 23, 2025 at 01:36:53PM +0000, Adam Reviczky wrote: > On Sun, 23 Nov 2025 06:18:58 -0500 Thomas Dickey < > [email protected]> wrote: > > On Sun, Nov 23, 2025 at 05:53:53AM -0500, Thomas Dickey wrote: > > > On Sun, Nov 23, 2025 at 05:24:16AM +0000, Adam Reviczky wrote: > > > > On Sat, 22 Nov 2025 13:26:16 -0500 Thomas Dickey < > > > > [email protected]> wrote: > > > > > On Sat, Nov 22, 2025 at 04:47:39PM +0100, Christian Marillat wrote: > > > > > > On 22 nov. 2025 10:13, Thomas Dickey <[email protected]> > > > > wrote: > > > > > > > > > > > > > On Sat, Nov 22, 2025 at 03:45:47PM +0100, Christian Marillat > wrote: > > > > > > >> Package: libncurses6 > > > > > > >> Version: 6.5+20251115-2 > > > > > > >> Severity: normal > > > > > > >> X-Debbugs-Cc: [email protected] > > > > > > >> > > > > > > >> Dear Maintainer, > > > > > > >> > > > > > > >> I can reproduce this issue with armhf, arm64, riscv64 > architectures > > > > > > >> > > > > > > >> zsh is the shell for theses arches. > > > > > > > > > > > > > > presumably both local and remote systems have comparable package > > > > versions. > > > > > > > > > > > > Yes, all have the same packages. > > > > > > > > > > > > >> downgrading ncurses related packages to 6.5+20250216-2 solve > this > > > > issue. > > > > > > > > > > > > > > there are at least three places where the problem might be: > > > > > > > > > > > > > > ncurses > > > > > > > zsh > > > > > > > terminal emulator > > > > > > > > > > > > > > A "typescript" from the "script" program would show what's > written to > > > > the > > > > > > > terminal, while the environment variables (and output of > infocmp) for > > > > > > > the local and remote systems would help with the discussion. > > > > > > > > > > > > E-mail send to quickly. > > > > > > > > > > > > Here is the remote output. > > > > > > > > > > The local and remote look much the same (agreeing with that). > > > > > Just to check, I updated my testing machine to unstable, and > > > > > (same terminal emulator, same shell) don't see this happening. > > > > > > > > > > I did a 'strings' on zsh and the main libraries (libtinfo6, libcap), > > > > > don't see "yes" compiled-in. It's not in the terminal description. > > > > > > > > > > Most of the changes for libtinfo since mid-February are specific to > > > > > the MinGW/Windows port. > > > > > > > > > > Since I don't use zsh, my test-configuration is pretty minimal. > > > > > I'm guessing that the "yes" comes from some program which is run > > > > > from your shell, e.g., for configuring the prompt. I checked > > > > > my configuration to see what zsh might run, by > > > > > > > > > > urxvt -e strace -fo trace.log zsh > > > > > > > > > > but in my case, there were no subprocesses of zsh. > > > > > > > > > > In your typescript files, for each case, the "yes" appears > immediately > > > > > before enabling or disabling bracketed paste, mode 2004 > > > > > (which may be coincidental). > > > > > > > > > > In my trace.log, I see the corresponding 2004's: > > > > > > > > > > 11657 write(10, "\33[1m\33[7m%\33[27m\33[1m\33[m "..., > 103) = > > > > 103 > > > > > 11657 write(10, "\r\33[m\33[27m\33[24m\33[Jprl-debiancur-6"..., 35) > = 35 > > > > > 11657 write(10, "\33[K", 3) = 3 > > > > > 11657 write(10, "\33[?2004h", 8) = 8 > > > > > 11657 write(10, "\33[?2004l", 8) = 8 > > > > > 11657 write(10, "\r\n", 2) = 2 > > > > > > > > > > In your configuration, you may see some different process writing > the > > > > "yes". > > > > > (Or if it's really zsh, the open's in the trace would probably > include the > > > > > file containing that "yes"). > > > > > > > > The 'yes' is printed out by zle with the 'terminfo' command. > > > > > > > > The specific lines from the system-wide zshrc are > > > > > https://salsa.debian.org/debian/zsh/-/blob/debian/debian/zshrc?ref_type=heads#L76:~:text=printf%20%27%25s%27%20%24%7Bterminfo%5Bsmkx%5D%7D > > > > and > > > > > https://salsa.debian.org/debian/zsh/-/blob/debian/debian/zshrc?ref_type=heads#L80:~:text=printf%20%27%25s%27%20%24%7Bterminfo%5Brmkx%5D%7D > > > > . > > > > > > > > You can test this by starting zsh without rc files: zsh -f > > > > > > I tried this, didn't see the problem, doing this to (try to) eliminate > my > > > environment: > > > > > > #!/bin/sh > > > unset TERMINFO > > > unset TERMINFO_DIRS > > > export TERM=xterm-256color > > On my ARM machine, I have run this with TERM=xterm-256color > (trace-xterm-256color.log), TERM= (trace-unset.log) and without "-f" for > zsh (trace-xterm-256color-full.log). > > Adam > > > > > as an afterthought, I recall this was using urxvt. > > Commenting out that TERM=, and trying with urxvt gave the same result. > > > > > strace -fo /tmp/trace.log zsh -f > > > > > > The shell doesn't show anything odd. > > > > -- > > Thomas E. Dickey <[email protected]> > > https://invisible-island.net
just looking at "zsh" and "open", I don't see anything really different
from my configuration (though I also added the "zsh-xxx" packages, just
to check):
> 8854 execve("/usr/bin/zsh", ["zsh", "-f"], 0x7fffd332bca8 /* 67 vars */) = 0
> 8854 newfstatat(AT_FDCWD, "/etc/zsh/zshenv.zwc", 0x7fffd58d8a18, 0) = -1
> ENOENT (No such file or directory)
> 8854 newfstatat(AT_FDCWD, "/etc/zsh/zshenv", {st_mode=S_IFREG|0644,
> st_size=623, ...}, 0) = 0
> 8854 openat(AT_FDCWD, "/etc/zsh/zshenv", O_RDONLY|O_NOCTTY) = 3
> 8854 read(11, "# /etc/zsh/zshenv: system-wide ."..., 8192) = 623
> 8854 openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/zsh/5.9/zsh/zle.so",
> O_RDONLY|O_CLOEXEC) = 3
> 8854 openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/zsh/5.9/zsh/complete.so",
> O_RDONLY|O_CLOEXEC) = 3
> 8854 openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/zsh/5.9/zsh/compctl.so",
> O_RDONLY|O_CLOEXEC) = 3
> 8896 execve("/usr/bin/zsh", ["zsh", "-f"], 0x7ffffcaa02e8 /* 67 vars */) = 0
> 8896 newfstatat(AT_FDCWD, "/etc/zsh/zshenv.zwc", 0x7fffd0161ec8, 0) = -1
> ENOENT (No such file or directory)
> 8896 newfstatat(AT_FDCWD, "/etc/zsh/zshenv", {st_mode=S_IFREG|0644,
> st_size=623, ...}, 0) = 0
> 8896 openat(AT_FDCWD, "/etc/zsh/zshenv", O_RDONLY|O_NOCTTY) = 3
> 8896 read(11, "# /etc/zsh/zshenv: system-wide ."..., 8192) = 623
> 8896 openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/zsh/5.9/zsh/zle.so",
> O_RDONLY|O_CLOEXEC) = 3
> 8896 openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/zsh/5.9/zsh/complete.so",
> O_RDONLY|O_CLOEXEC) = 3
> 8896 openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/zsh/5.9/zsh/compctl.so",
> O_RDONLY|O_CLOEXEC) = 3
ltrace can also show pertinent details, but in a quick check of that,
I see only "yes" found when reading the /usr/bin directory (and that's
expected).
--
Thomas E. Dickey <[email protected]>
https://invisible-island.net
signature.asc
Description: PGP signature
