1

Problem

I coincidentally was trying to print a string to STDOUT in gnome-terminal that contains a lot of square brackets and noticed it took a lot of IO time (~4sec for ~100KB). To confirm that there is something specific about that string, I printed another string of the length, and the time is very different.

Specifically:

$ time cat file1
# ... snip ...
real    0m3.968s
user    0m0.004s
sys 0m0.001s

$ time cat file2


... snip ...


real    0m0.052s
user    0m0.006s
sys 0m0.001s


$ ls -l file*
-rw-rw-r-- 1 sinan sinan 115441 Dec 19 16:38 file1
-rw-rw-r-- 1 sinan sinan 115441 Dec 19 16:38 file2

I cannot tell what is the cause of the slowdown, I suspect something in gnome-terminal parses square brackets and gives them a special meaning. Does anyone have any idea?

Version Information

  • gnome-terminal --version: GNOME Terminal 3.36.2 using VTE 0.60.3 +BIDI +GNUTLS +ICU +SYSTEMD
  • bash --version: GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)
Karthik Nedunchezhiyan
  • 777
Sinan Taifour
  • 113
  • My guess is that bash performs a lot of tests ( test == [ ), which take some time -- see here: https://linux.die.net/man/1/test – Andre Wildberg Dec 19 '20 at 20:19
  • @AndreWildberg I doubt it. The shell should not interact with the data that is outputted by cat. However, the terminal might be interested in doing syntax highligting or something similar. – Kusalananda Dec 19 '20 at 20:28
  • I tried the first file in my gnome-terminal and it works instantly. Gnome-terminal version 3.28.2, bash 4.4.20, Ubuntu 18.04.05 64bit. Same in xfce4-terminal. – stackzebra Dec 20 '20 at 10:59
  • See the bash variable PS1 which is the prompt. There are square-brackets e.g. for changing the title of the terminal and so on. – Marco Dec 24 '20 at 07:27
  • 1
    Filed upstream issue: https://gitlab.gnome.org/GNOME/vte/-/issues/343 – egmont Mar 24 '21 at 22:37
  • A workaround is to disable bidi, either using printf "\e[8l" (lasts up to a reset or so, you might want to embed it in your prompt), or globally as a hidden gnome-terminal setting, by navigating dconf-editor to /org/gnome/terminal/legacy/profiles:/:<the-profile-ID>/enable-bidi. – egmont Mar 25 '21 at 00:36
  • Observed again: https://unix.stackexchange.com/questions/674773/why-does-gnome-terminal-lag-when-using-brackets-or-parentheses – Gilles 'SO- stop being evil' Oct 25 '21 at 20:37

1 Answers1

2

Egmont reported the bug on the vte bug tracker (vte is a terminal emulator library used by gnome-terminal, anjuta, deepin-terminal, gtkterm, lilyterm, lxterminal, mate-terminal, remmina, sakura, tilda, vinagre, xfce4-terminal, …). It turned out to be a bug in the underlying fribidi library, which is unfixed as of October 2021.

Workaround: disable bidirectional support

Egmont also suggests a workaround which is to disable bidirectional support. Obviously, that workaround only helps if you don't care about bidi support.

For Gnome-terminal, you can do it via a hidden setting which has to be applied to each profile. The following command does this permanently for your account:

for p in $(dconf list /org/gnome/terminal/legacy/profiles:/); do dconf write /org/gnome/terminal/legacy/profiles:/${p%/}/enable-bidi false; done

For any vte-using terminal, you can disable bidi support temporarily with

printf '\e[8l'

but this only lasts until the terminal is reset. If you put this in your shell prompt, it'll help in command line applications, but not in full-screen applications. In bash:

PS1='\[\e[8l\]'$PS1

In zsh:

PS1='%{\e[8l%}'$PS1

A more general terminal-independent way to effectively disable bidi support is to change the terminal's reset sequence to include \e[8l. The terminal name (value of $TERM) in vte is xterm-256color. See How to stop cursor from blinking for explanations. This command will only affect new terminals, not ones that are already open.

TERM=xterm-256color infocmp -1 | sed '/^.rs[12]=/ s/,$/\\E[8l,/' | tic -
Gilles 'SO- stop being evil'
  • 829,060