Description of problem: Currently using GNOME Terminal 3.32.2 using VTE 0.56.3 +GNUTLS In gnome-terminal on various x86_64 based systems, up-arrow a few times, or Ctl-r a couple times, and the cursor and text get splattered on different terminal lines or in different spaces on the same line. Also, long commands do not wrap correctly. to the following line. This makes any editing of command lines virtually impossible. All this worked fine with F29. Version-Release number of selected component (if applicable): GNOME Terminal 3.32.2 using VTE 0.56.3 +GNUTLS How reproducible: 100% Steps to Reproduce: 1. Recall a few previous commands and try to edit. 2. Write a long command that should wrap to the next line 3. Actual results: Mismatched placement of text and cursor on the terminal screen. Expected results: Text and cursor should be properly aligned on the screen. Additional info: Using cinnamon desktop, but I get the same results with mate-terminal on the mate desktop. I've experienced this on three different systems and a virtual system, so I believe it is not hardware related.
mclasen gave me a tip that any special characters in my prompt string could cause incorrect calculation of the prompt string width. I do have special characters in my prompt string, and when I remove them, the problem no longer exists. HOWEVER, this remains a regression from F29. ANSI codes in the prompt string, or anywhere on the command line, should be correctly rendered for the appropriate length, which I'm assuming should be zero, since they are escape codes.
You might have to encapsulate terminal escape sequences within \[ and \]. Here's an example of such a change: https://github.com/debarshiray/toolbox/commit/bc1a816ea3b80fc7c3dc5d523838256e94c953d2
I did as you suggested and escaped [] with \[ and \], and it fixed the problem. I'm wondering if earlier releases will respond correctly to the escaped brackets.
(In reply to Tony Camuso from comment #3) > I did as you suggested and escaped [] with \[ and \], and it fixed the > problem. > > I'm wondering if earlier releases will respond correctly to the escaped > brackets. The escaped brackets work fine on Fedora 29, at least. I know because I still have a Fedora 29 system around that use regularly.
Thanks. I can close this. But one more question. If I have problems with escaped brackets in other distros, what can I test for? gnome-terminal version would be my guess, but is it something else?
(In reply to Tony Camuso from comment #5) > If I have problems with escaped > brackets in other distros, what can I test for? gnome-terminal version would > be my guess, but is it something else? The terminal emulation is performed by a library called VTE. It provides a GTK widget called VteTerminal that's used by any terminal emulation application that's written in GTK. eg., gnome-terminal, tilix, xfce-terminal, terminals embedded in various other GTK applications like IDEs and so on. The most visible applications that don't use VTE would be Konsole and xterm. Given that, I'd look at the VTE_VERSION environment variable, or the version of the VTE RPM, if we are only talking about GTK-based applications. Note that the naming of the VTE RPM can be very confusing at times. Thanks to an ABI bump some time ago, and the fact that you can have GTK2-based VteTerminal and a GTK3-based VteTerminal. Sorry about that, but I didn't choose the names. Honestly. :) gnome-terminal uses a package called vte291 in Fedora.
This is actually not a bug, since the terminal software requires escaped brackets to correctly calculate prompt string length. Those who don't use custom prompt strings won't experience any problem. Those who do, must escape brackets so that, if you want brackets in your prompt, you have to express them as "\[[" and "\]]" respectively.
Unfortunately, it doesn't seem to matter whether there are brackets in the prompt string. If there are ANSI escape codes in the prompt string, then previous commands are uneditable and long commands to not wrap correctly. This is a regression from F29. Here are the ANSI codes I use. I need the colors and bold, because I have vision challenges that are helped by them. These worked flawlessly in F29. ----------------------------------------------------------- # # Text Attributes # unset BLD && declare BLD="\033[1m" unset UND && declare UND="\033[4m" unset OFF && declare OFF="\033[0m" # # Text color definitions # unset BLK && declare BLK='\[\e[0;30m\]' unset RED && declare RED='\[\e[0;31m\]' unset GRN && declare GRN='\[\e[0;32m\]' unset YEL && declare YEL='\[\e[0;33m\]' unset BLU && declare BLU='\[\e[0;34m\]' unset MGT && declare MGT='\[\e[0;35m\]' unset CYN && declare CYN='\[\e[0;36m\]' unset WHT && declare WHT='\[\e[0;37m\]' # # Bright colors # unset BBLK && declare BBLK='\[\e[1;90m\]' unset BRED && declare BRED='\[\e[1;91m\]' unset BGRN && declare BGRN='\[\e[1;92m\]' unset BYEL && declare BYEL='\[\e[1;93m\]' unset BBLU && declare BBLU='\[\e[1;94m\]' unset BMGT && declare BMGT='\[\e[1;95m\]' unset BCYN && declare BCYN='\[\e[1;96m\]' unset BWHT && declare BWHT='\[\e[1;97m\]' if [ $(id -u) -eq 0 ]; then # you are root, set root prompt export PS1="\[[$BRED\u$BRED@$BGRN\h $BYEL\W$OFF\]]$BRED# $OFF" else # normal user export PS1="\[[$BMGT\u$BRED@$BGRN\h $BYEL\W$OFF\]]$BMGT$ $OFF" fi ------------------------------------------------------------------------ Please advise.
Check the behavior in xterm. If it's the same (as I expect) then it's not a vte / gnome-terminal bug. > This is actually not a bug, since the terminal software requires escaped brackets to correctly calculate prompt string length. The escaped brackets do not reach the terminal emulator. They are handled by bash (your shell) in order to calculate how to paint the prompt. I'm almost sure it's a regression in bash. At least, I've already encountered one relatively complex prompt that was handled correctly by bash-4.4 but not by bash-5.0. (F29 ships 4.4, F30 ships 5.0.)
Sorry, I revoke my previous statement about a likely bash bug. It simply looks like a faulty prompt definition. - You nest escaped brackets, I'm not sure what bash does then, I guess you're just not supposed to do it. - You enclose in escaped brackets printable stuff just as [, \u, @, \h, space, \W. You shouldn't. - You don't enclose in escaped brackets the trailing $OFF of your prompt. You should. As a fix, you should probably add those \[ \] to BLD and friends, and remove directly from PS1. User error, should be closed as NOTABUG.
(In reply to Egmont Koblinger from comment #10) > Sorry, I revoke my previous statement about a likely bash bug. It simply > looks like a faulty prompt definition. > > - You nest escaped brackets, I'm not sure what bash does then, I guess > you're just not supposed to do it. > > - You enclose in escaped brackets printable stuff just as [, \u, @, \h, > space, \W. You shouldn't. > > - You don't enclose in escaped brackets the trailing $OFF of your prompt. > You should. > > As a fix, you should probably add those \[ \] to BLD and friends, and remove > directly from PS1. > > User error, should be closed as NOTABUG. Your recommendation above fixed the problem, so NOTABUG.