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
strace -fo /tmp/trace.log zsh -f
The shell doesn't show anything odd.
--
Thomas E. Dickey <[email protected]>
https://invisible-island.net
trace.log.gz
Description: application/gzip
signature.asc
Description: PGP signature
