#23 bashrc: Don't set up VTE-specific PROMPT_COMMAND
Merged 3 years ago by landgraf. Opened 3 years ago by rishi.
rishi/setup wip/rishi/ignore-vte  into  master

file modified
@@ -19,8 +19,6 @@ 


          if [ -e /etc/sysconfig/bash-prompt-xterm ]; then


-         elif [ "${VTE_VERSION:-0}" -ge 3405 ]; then

-             PROMPT_COMMAND="__vte_prompt_command"


              PROMPT_COMMAND='printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"'


file modified
+4 -1
@@ -1,6 +1,6 @@ 

  Summary: A set of system configuration and setup files

  Name: setup

- Version: 2.13.8

+ Version: 2.13.9

  Release: 1%{?dist}

  License: Public Domain

  Group: System Environment/Base
@@ -115,6 +115,9 @@ 




+ * Tue Jan 12 2021 Debarshi Ray <rishi@fedoraproject.org> - 2.13.9-1

+ - Don't set up VTE-specific PROMPT_COMMAND in bashrc


  * Mon Nov 30 2020 Pavel Zhukov <pzhukov@redhat.com> - 2.13.8-1

  - Do not import bashrc for posix shell


First of all, VTE ships its own Bash configuration snippet in
/etc/profile.d/vte.sh that already does this and provides the
definition of the __vte_prompt_command function. So it's better to let
VTE own its own configuration.

Secondly, this creates problems in interactive Bash instances running
inside a container that doesn't have VTE installed but has the
VTE_VERSION environment variable set, because PROMPT_COMMAND tries to
access a missing __vte_prompt_command function. This is observed in
Toolbox containers created from the Red Hat Universal Base Image.
Toolbox containers inherit environment variables like TERM and
VTE_VERSION from the host so that interactive shells inside the
container are configured like the ones on the host. However, UBI
doesn't have /etc/profile.d/vte.sh. Hence, instead of silently ignoring
the VTE-specific configuration bits, PROMPT_COMMAND ends up trying to
access a missing __vte_prompt_command function.

rebased onto 718cfa4

3 years ago

Not that I ever used it myself but /etc/profile.d/vte.sh is in fact installed by vte-profile, which is required by vte291 but not by vte. Anyway, no objections to the change in question from me.

The names of the VTE packages in Fedora are a mess. There's only one upstream project, and that's called VTE. However, in Fedora we have vte (old VTE API/ABI built with GTK2), vte3 (old VTE API/ABI built with GTK3) and vte291 (current VTE API/ABI built with GTK3).

Pull-Request has been merged by landgraf

3 years ago

Hi @rishi ,

I haven't noticed until recently and only after backporting this change to RHEL8.7/9.1 that I can see there are still remnants of:


in /etc/bashrc:


the extra "vte*" string. Without it it would hit this code branch instead:


Wondering whether we can remove it too or there was some background reason you kept it there.

Hey @mosvald ,

Thanks for digging into this!

tl;dr: You can drop the vte* string, but it will be a clean-up, and not a fix, because currently it doesn't cause any problem.

If you look closely, you will notice that when running any terminal emulation application that's based on VTE (eg., GNOME Terminal, Tilix, etc.), the TERM environment variable is set to xterm-256color. It's been like this for 7.5 years now. Earlier it used to be xterm.

As far as I can make out from Git, VTE never set TERM to anything that started with vte. At least not since 2004, because I tracked the changes back to that era.

For some unknown reason, VTE's own Bash configuration snippet introduced these lines in 2013:

case "$TERM" in

... and I suspect that got copied into Fedora's /etc/bashrc.

Unless I am mistaken, I think the vte* was always unused.

I didn't remove the vte* from my initial commit to reduce the footprint of the change, so that it's easier to backport without any unintended consequences. I think it should be safe to remove it in Rawhide, but there's no urgency to do that in older branches, because it's not causing any problems.

Unless I am mistaken, I think the vte* was always unused.

I discussed this with Christian Persch, the upstream VTE maintainer.

VTE itself never set TERM to vte* (or, gnome*) . Those were invented by the terminfo maintainer, who is also the xterm maintainer, and thinks that no other terminal emulator should set TERM to xterm*.

So, I think you can drop the vte* from Fedora's /etc/bashrc in Rawhide, because I think VTE's /etc/profile.d/vte.sh is sourced after it and ends up getting preferred.

tl;dr: You can drop the vte* string, but it will be a clean-up,
and not a fix, because currently it doesn't cause any problem.

Done: https://pagure.io/setup/pull-request/37