Bug 1729110 - gnome-terminal command line recalls are not editable
Summary: gnome-terminal command line recalls are not editable
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-terminal
Version: 30
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Debarshi Ray
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-11 12:29 UTC by Tony Camuso
Modified: 2020-01-09 19:09 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-01-09 19:08:20 UTC


Attachments (Terms of Use)

Description Tony Camuso 2019-07-11 12:29:33 UTC
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.

Comment 1 Tony Camuso 2019-07-24 14:25:33 UTC
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.

Comment 2 Debarshi Ray 2019-07-24 14:37:35 UTC
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

Comment 3 Tony Camuso 2019-07-25 17:21:09 UTC
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.

Comment 4 Debarshi Ray 2019-07-25 18:10:23 UTC
(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.

Comment 5 Tony Camuso 2019-07-25 20:19:22 UTC
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?

Comment 6 Debarshi Ray 2019-07-26 11:17:02 UTC
(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.

Comment 7 Tony Camuso 2019-07-26 13:23:18 UTC
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.

Comment 8 Tony Camuso 2019-08-22 14:30:42 UTC
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.

Comment 9 Egmont Koblinger 2019-09-02 18:58:10 UTC
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.)

Comment 10 Egmont Koblinger 2019-09-02 19:04:58 UTC
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.

Comment 11 Tony Camuso 2020-01-09 19:09:01 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.