Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
The terminal keeps printing stray:
#2004l
?2004h#
characters. Checking bash source code we see the pattern:
.../bash/bash-4.4/lib/readline/rlprivate.h:#define BRACK_PASTE_PREF "\033[200~"
.../bash/bash-4.4/lib/readline/rlprivate.h:#define BRACK_PASTE_SUFF "\033[201~"
.../bash/bash-4.4/lib/readline/rlprivate.h:#define BRACK_PASTE_LAST '~'
.../bash/bash-4.4/lib/readline/rlprivate.h:#define BRACK_PASTE_SLEN 6
.../bash/bash-4.4/lib/readline/rlprivate.h:#define BRACK_PASTE_INIT "\033[?2004h"
.../bash/bash-4.4/lib/readline/rlprivate.h:#define BRACK_PASTE_FINI "\033[?2004l"
Note the 2004h and 2004l
For the moment, user is using the workaround:
set enable-bracketed-paste 0
in $HOME/.inputrc
Apparently the terminal emulator is web based, and keeps line edit
locally, then "pastes" it, and due to some bad iteration, prints that
noise.
Apparently the software with the issue is https://www.censoft.com/
Note that this should be a bug in third party application. This
bug report is basically only to document the issue.
Software vendor tells it is not a bug in their terminal but in Linux.
From my understanding, could need to patch bash a bit in
terminal.c:_rl_init_terminal_io() and check for known terminal values,
at first, I would suggest an inverted logic. And have
_rl_enable_bracketed_paste default to zero instead of one, and only
switch to one if TERM matches xterm*.
The current behavior is to have it enabled by default, and unset if
tgetent() fails or if TERM is "dumb".
This is just an idea, but I believe it is still better to keep as is,
because bracketed paste mode is very useful if one is for example,
doing some tutorial and blindly copy&pasting commands from web pages.
Eventually it was found that the TERM is being explicitly chosen
in the terminal emulator configuration interface.
Also, bash was not enabling bracketed paste mode. But it can be
made to enable if installing the ncurses-term package, that will
provide /usr/share/terminfo/w/wyse60-25
Either way, gnome-terminal, konsole and xterm do not show the
issue experienced by the user with the third party terminal
emulator, but have other issues leaving artifacts in the screen.
If anything, a bug report should be opened for terminal emulator
about the artifacts, e.g. command clear does not clean the
screen, scrow up/down does not clear to end of line.
Another example is:
tput cup 0 0
that only moves to the start of the line, so, maybe wyse60-25
is a "true tty" that mimics a printer...
Reopening to ask for possibly only enabling bracketed paste mode
if the terminal type is xterm*. That is, the usual default for
a graphical interface, where the bracketed paste mode is more
likely to be useful.
Comment 5Siteshwar Vashisht
2023-01-05 13:34:30 UTC
The terminal type may change if you use a multiplexer like `tmux`, `screen` etc. Bracketed paste mode should be kept on by default and if it doesn't work, it's easy to disable it. This issue should be documented in a KCS.