Your message dated Thu, 07 May 2026 11:11:41 +0200 with message-id <[email protected]> and subject line Close as unreproducible has caused the Debian Bug report #886813, regarding screen: GNU screen wipes X selection (copy buffer / clipboard) on init with TERM=xterm-256color to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 886813: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886813 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: screen Version: 4.5.0-6 Severity: normal Tags: patch Dear Maintainer, for bug #134198 ("konsole behaves oddly with the default xterm init_2string/:is terminfo description") from 2002, a fix was added into /etc/screenrc that goes like this: # Change the xterm initialization string from is2=\E[!p\E[?3;4l\E[4l\E> # (This fixes the "Aborted because of window size change" konsole # symptoms found # in bug #134198) termcapinfo xterm 'is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l' That fix also fixes the following problem: "Soft reset shouldn't wipe out selection" (2017) https://bugzilla.gnome.org/show_bug.cgi?id=789954 that has plagued gnome-terminal for quite some time now. The '\e[!p' wipes the contents of the selection if you're using a GNOME VTE widget (which gnome-terminal does). For older graphical desktops, the TERM env inside a gnome-terminal would be set to xterm, but newer ones (at least on Ubuntu Xenial through Artful) get TERM=xterm-256color by default and there the problems reappeared. Instead of the "fixed" is= description, we get the original one with '\e[!p' and our selection is emptied upon screen startup. Can we get the screenrc fix replaced by one that also matches xterm-256color to fix the VTE bug as well? Adding an asterisk would suffice: termcapinfo xterm* 'is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l' Steps to reproduce: - fire up gnome-terminal - put something in X selection - start screen: TERM=xterm-256color screen - observe how the selection has been cleared Yes, I am aware that this should ideally be fixed in VTE, as screen simply uses the :is= description as intended. But since the konsole workaround has fixed this issue in the past, it might as well fix it in the future as well. And since my google-fu didn't turn up much about this issue, a bit more exposure through this tracker wouldn't hurt either. An alternative workaround for the gnome-terminal is to manually set a custom command with TERM=xterm: $ dconf dump /org/gnome/terminal/legacy/profiles:/ | grep command custom-command='/usr/bin/env TERM=xterm /bin/bash' use-custom-command=true Cheers, Walter Doekes OSSO B.V. -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages screen depends on: ii libc6 2.24-11+deb9u1 ii libpam0g 1.1.8-3.6 ii libtinfo5 6.0+20161126-1+deb9u1 screen recommends no packages. Versions of packages screen suggests: pn byobu | screenie | iselect <none> ii ncurses-term 6.0+20161126-1+deb9u1 -- Configuration Files: /etc/screenrc changed [not included] -- no debconf information
--- End Message ---
--- Begin Message ---Thanks for the report. This bug has been tagged as unreproducible since 2018 with no update. If this is still reproducible on current unstable (5.0.1-1), please raise a new bug.
--- End Message ---
