Fedora 33 : vte configuration fixes no longer work.

[asegarra]

Sourcing vte.sh or using login shell no longer work in Fedora 33, any ideas what's going on and how to fix it?

[khurlic]

Not sure if this will work for you. I had the same issue. I ended up putting the following code block at the top of my ${HOME}/.bash_profile file and the vte configuration pop window went away.

if [ $TILIX_ID ] || [ $VTE_VERSION ]; then
        source /etc/profile.d/vte.sh
fi

Im using a stock ${HOME}/.bashrc and ${HOME}/.bash_profile file.

Im running Fedora 33

Here's my tilix version info

 tilix -v
Versions
    Tilix version: 1.9.1
    VTE version: 0.62
    GTK Version: 3.24.23

Tilix Special Features
    Notifications enabled=1
    Triggers enabled=0
    Badges enabled=1

Under the Preferences -> Profiles -> Default -> Command options. I've tried with "Run command as a login shell" <- that worked. I've also tried with "Run a custom command instead of my shell" <- that worked and I tried with both option checked and ti worked.

[spavezv]

I'm having the same issue. Sourcing vte.sh file does work with bash, but now with zsh.

[Frederik-Baetens]

@khurlic i'm also on f33 and that fix doesn't seem to work for me, even with run command as login shell enabled :disappointed:

I made a fedora bug report a while back: https://bugzilla.redhat.com/show_bug.cgi?id=1888447

[Frederik-Baetens]

For those looking to get back to happily tiling for now, the following .tmux.conf (place that in your home directory) emulated my tilix use case pretty well. You can configure tilix (& other terminals) to start tmux directly when you open the terminal.

bind -n M-d split-window -c "#{pane_current_path}"
bind -n M-r split-window -h -c "#{pane_current_path}"
bind -n M-c new-window -c "#{pane_current_path}"
bind -n M-down select-pane -D
bind -n M-up select-pane -U
bind -n M-left select-pane -L
bind -n M-right select-pane -R

[Frederik-Baetens]

This is also broken in kitty, so I don't think tilix has much to do with this problem.

[zeten30]

BTW: It works as expected with fish shell (custom-command /usr/bin/fish). Tiling or new tab follows working dir.

[sandzhaj]

any solutions for f33?

[zeten30]

@sandzhaj I actually switched to Fish + Starship prompt. I was thinking about it even before and this problem finally forced me to do it.

Not for everyone, but I'm satisfied and I'd recommend to try it:)

Keep eye on https://bugzilla.redhat.com/show_bug.cgi?id=1888447

[Alexound]

Problem persists, Fedora 33. Tiling work correct right after the installation and breaks after first update.

[zeten30]

@Alexound can you please share the version diff of vte* packages - 'after install' versus 'after upgrade'

# this should be the latest
rpm -qa | grep vte
vte-profile-0.62.1-1.fc33.x86_64
vte291-0.62.1-1.fc33.x86_64

Or you can try to downgrade vte291 packages (vte291 builds) - https://koji.fedoraproject.org/koji/packageinfo?packageID=18494

[Alexound]

@zeten30: I've tried to downgrade package to several different versions with no effect. If I'll have some time available I'll try to reproduce the issue on VM.

[zeten30]

It can be caused by 'other package' update. Thinking what else can be related.. bash itself??

I'll also try to reproduce in VM.

[zeten30]

@Alexound I cannot confirm that it works after installation. It's broken even after vanilla install. Tilix complains about VTE configuration... Gnome-terminal new tab is starting in working folder.

[Alexound]

@zeten30 I apologize, I might have mistaken with this. BTW, the very same issue occurs on latest openSUSE Tumbletweed. Update: Same with Debian Testing release.

[Frederik-Baetens]

Splitting still works in terminator while being broken in tilix & kitty, so there should still be a proper way to do splitting while remembering the working dir on fedora.

Terminator is however noticably "slower" than tilix when splitting tiles etc...

[Frederik-Baetens]

The fedora people are suspecting a bug in a newer version of Tilix because terminator, and gnome terminal (when opening new tabs) still perfectly manage to remember the current working directory.

[radek-svanda-elder]

Hi, I did a bit of investigation on Fedora 33 Silverblue and found the problem/workround (sorry, long post):

VTE works just fine in the toolbox session, not on the host system. This was the lead. The problem is with the HOSTNAME variable that is set in /etc/profile:

./profile:45:HOSTNAME=`/usr/bin/hostnamectl --transient  2>/dev/null`

Both functions __vte_prompt_command and __vte_osc7 defined in /etc/profile.d/vte.sh use that variable.

__vte_osc7 () {
  printf "\033]7;file://%s%s\033\\" "${HOSTNAME}" "$(/usr/libexec/vte-urlencode-cwd)"
}

__vte_prompt_command() {
  local command=$(HISTTIMEFORMAT= history 1 | sed 's/^ *[0-9]\+ *//')
  command="${command//;/ }"
  local pwd='~'
  [ "$PWD" != "$HOME" ] && pwd=${PWD/#$HOME\//\~\/}
  pwd="${pwd//[[:cntrl:]]}"
  printf '\033]777;notify;Command completed;%s\033\\\033]777;precmd\033\\\033]0;%s@%s:%s\033\\' "${command}" "${USER}" "${HOSTNAME%%.*}" "${pwd}"
  __vte_osc7
}

If I set HOSTNAME to empty value at the end of my .bashrc, VTE in Tilix starts working.

@@ -8,10 +8,10 @@
 + '[' /var/home/radek/Documents '!=' /var/home/radek ']'
 + pwd='~/Documents'
 + pwd='~/Documents'
-+ printf '\033]777;notify;Command completed;%s\033\\\033]777;precmd\033\\\033]0;%s@%s:%s\033\\' 'set -x __vte_prompt_command' radek fedora '~/Documents'
++ printf '\033]777;notify;Command completed;%s\033\\\033]777;precmd\033\\\033]0;%s@%s:%s\033\\' 'set -x __vte_prompt_command' radek '' '~/Documents'
 + __vte_osc7
 ++ /usr/libexec/vte-urlencode-cwd
-+ printf '\033]7;file://%s%s\033\' fedora /var/home/radek/Documents
++ printf '\033]7;file://%s%s\033\' '' /var/home/radek/Documents
 ++ __vte_prompt_command
 +++ HISTTIMEFORMAT=
 +++ history 1
@@ -22,7 +22,7 @@
 ++ '[' /var/home/radek/Documents '!=' /var/home/radek ']'
 ++ pwd='~/Documents'
 ++ pwd='~/Documents'
-++ printf '\033]777;notify;Command completed;%s\033\\\033]777;precmd\033\\\033]0;%s@%s:%s\033\\' 'set -x __vte_prompt_command' radek fedora '~/Documents'
+++ printf '\033]777;notify;Command completed;%s\033\\\033]777;precmd\033\\\033]0;%s@%s:%s\033\\' 'set -x __vte_prompt_command' radek '' '~/Documents'
 ++ __vte_osc7
 +++ /usr/libexec/vte-urlencode-cwd
-++ printf '\033]7;file://%s%s\033\' fedora /var/home/radek/Documents
+++ printf '\033]7;file://%s%s\033\' '' /var/home/radek/Documents

I do not know other implications of having the HOSTNAME variable set to an empty string so in the end I resorted to copy those two functions to .bashrc and removing that variable there.

Hope this helps.

[zeten30]

Yes, definitely related to hostname. Another potential workaround is to set hostname. See this:

^ This is installation without hostname - (defaults to localhost.localdomain). Tilix is not working - reporting VTE issues.

I've tried to change hostname, but it didn't helped immediately. Then I've set the hostname and added entry to /etc/hosts. It's working after reboot:

Good job @radek-svanda-elder !

[Frederik-Baetens]

So whose responsibility is this? Should fedora configure the hostname differently or should tilix be able to deal with what fedora does?

So is the problem that the hostname is defined after vte.sh is called? Or what's the exact problem with how that hostname is defined?

[asegarra]

It works for me just by changing the default hostname, did not have to edit /etc/hosts as @zeten30 did, no sourcing vte.sh and no reboot required just restarting the app. Curiously if I change the hostname back to localhost.localdomain it stops working and noticed that hostnamectl is reporting a transient hostname in this case but not if I set hostname to something else.

[zeten30]

yes.. I did another test.. /etc/hosts piece is not required. I'd say it should be handled by vte. Scripts should just work, no matter what your hostname is:)

[Frederik-Baetens]

Is this suddenly fixed for anyone else? Might be a coincidence, or something random, but it suddenly works again on my f33 machine.

[debarshiray]

I see that on Fedora 32, /etc/profile had:

HOSTNAME=`/usr/bin/hostname 2>/dev/null`

... whereas on Fedora 33, it's:

HOSTNAME=`/usr/bin/hostnamectl --transient 2>/dev/null`

I wonder why it changed.

The fix might just be to use ${HOSTNAME%%.*} in the __vte_osc7 function in /etc/profile.d/vte.sh. That's already the case in the other instance of HOSTNAME in the file.

[asegarra]

Is this suddenly fixed for anyone else? Might be a coincidence, or something random, but it suddenly works again on my f33 machine.

No, just tried it and the only way it works is if my hostname is something other than the default localhost.localdomain. Btw I no longer need to source vte.sh for it to work properly.

[debarshiray]

Here's the commit that introduced the change: https://pagure.io/setup/c/eb9cc4dce89be24f5b343cc3b3f146169181ec5a

[Akiyamka]

So, what I can do to solve vte configuration error at fedora 33? Change in /etc/profile HOSTNAME to

`/usr/bin/hostname 2>/dev/null`

it's only way? Can it break something else?

The fix might just be to use ${HOSTNAME%%.*} in the __vte_osc7 function in /etc/profile.d/vte.sh. 

Unfortunately it didn't help

[Alexound]

So, what I can do to solve vte configuration error at fedora 33? Change in /etc/profile HOSTNAME to

`/usr/bin/hostname 2>/dev/null`

it's only way? Can it break something else?

The fix might just be to use ${HOSTNAME%%.*} in the __vte_osc7 function in /etc/profile.d/vte.sh. 

Unfortunately it didn't help

The easiest way, as mentioned above, to use hostnamectl and change the default 'localhost' hostname to something else.

[nos1609]

For me on F34 it worked with vte-devel install, don't really know which of the 45 deps made the trick, but no warning at all on a fresh install.

[CodeWitchBella]

For me this was fixed by setting the hostname, which could also be done using gui in gnome.

System Settings > Sharing > Computer Name and log out and back in to refresh env variables.

[debarshiray]

On a freshly installed Fedora 33 Workstation:

[rishi@localhost ~]$ hostnamectl --transient 
fedora
[rishi@localhost ~]$ hostnamectl
   Static hostname: localhost.localdomain
Transient hostname: fedora
         Icon name: computer-vm
           Chassis: vm
        Machine ID: 7ff908d3de7a4f2da32c1ea976e103c2
           Boot ID: 932f0934cfa94a849bef6d8d01450e2e
    Virtualization: kvm
  Operating System: Fedora 33 (Workstation Edition)
       CPE OS Name: cpe:/o:fedoraproject:fedora:33
            Kernel: Linux 5.8.15-301.fc33.x86_64
      Architecture: x86-64

It turns out that the static and transient hostnames are set to different values. While the Bash prompt uses the static hostname, the mechanism to track the current working directory in /etc/profile.d/vte.sh uses the transient value through the HOSTNAME environment variable.

Under such circumstances, Tilix is indeed unable to track the current working directory and opens new terminals in $HOME, but GNOME Terminal somehow manages to keep tracking successfully. It looks like the two applications have some subtly different assumptions in the code, and it's possible that Tilix might have bet on the wrong horse.

[debarshiray]

The problem lies in Tilix's GlobalTerminalState class.

Tilix uses the hostname component of the current directory URI (eg., file://<hostname/path/to/directory) to differentiate between local and remote hosts. However, it uses gethostname(2) to get the local hostname which isn't able to differentiate between transient and static hostnames. So, in case, those are different, it gets confused and mistakes the local path as remote.

I'd suggest using systemd-hostnamed to query the local hostname. Specifically the /org/freedesktop/hostname1 D-Bus object on the org.freedesktop.hostname1 system service implements the org.freedesktop.hostname1 D-Bus interface that offers the Hostname (or the transient hostname) and StaticHostname properties.

gethostname could still be kept as a fallback for OSes without systemd-hostnamed.

[debarshiray]

GNOME Terminal doesn't try to differentiate between local and remote hosts, which is why it doesn't hit this problem.

[debarshiray]

I believe this got fixed in Fedora 34.

Until Fedora 33, there were a lot of oddities in how the hostname got set in a default installation of Fedora Silverblue and Workstation, before the user went and explicitly set one statically (through Settings, for example).

Anaconda put localhost.localdomain in /etc/hostname, and systemd would try to smartly dodge that value as not a static hostname set by the user and fallback to a transient hostname obtained through DHCP or the hard-coded fallback hostname of fedora.

Unfortunately, those 'smarts' in systemd weren't smart enough, and it got it wrong in some cases. For example, it would still call sethostname(2) with localhost.localdomain from /etc/hostname to set the hostname in the kernel when booting. Of course, the kernel doesn't know about static, transient and fallback hostnames. So, commands like hostname(1) and uname --nodename or the uname(2) system call would return localhost.localdomain, while hostnamectl hostname --transient would return fedora.

Note that, with the GNU C Library, the gethostname(2) system call is implemented in terms of uname(2).

This is why, on a freshly installed Fedora Silverblue or Workstation 33, the hostname in the Bash prompt and GNOME Terminal's (and also Tilix's?) headerbar didn't match. The former used uname(2) and shortened it to localhost, while the latter used hostnamectl --transient and got fedora. This in turn broke Tilix's logic to differentiate between local and remote hosts, and led to this bug.

All this got straightened out in Fedora 34.

Anaconda no longer puts localhost.localdomain in /etc/hostname on its own. /etc/hostname is empty unless the user goes and explicitly sets a static hostname (through Settings, for example). systemd no longer tries to special case localhost.localdomain. It simply assumes that if /etc/hostname has something, then it's the static hostname, else there's no static hostname.

See this Fedora bug, and the upstream Anaconda and systemd pull requests linked from it, for the full details.

So, this is how it looks like on Fedora 34 Silverblue:

[rishi@fedora ~]$ cat /etc/hostname

[rishi@fedora ~]$ hostname
fedora
[rishi@fedora ~]$ uname -n
fedora
[rishi@fedora ~]$ hostnamectl --transient 
fedora
[rishi@fedora ~]$ echo $HOSTNAME
fedora
[rishi@fedora ~]$ hostnamectl status
   Static hostname: n/a                                                         
Transient hostname: fedora
         Icon name: computer-vm
           Chassis: vm
        Machine ID: 9c5968e4a24c4f2088419cd01fa1950b
           Boot ID: b7502d0268f94c4cba91889ea1c46ace
    Virtualization: qemu
  Operating System: Fedora 34.20210423.n.0 (Sil…
       CPE OS Name: cpe:/o:fedoraproject:fedora:34
            Kernel: Linux 5.11.12-300.fc34.x86_64
      Architecture: x86-64
   Hardware Vendor: QEMU
    Hardware Model: Standard PC _Q35 + ICH9, 2009_
[rishi@fedora ~]$ 

Compare this to my earlier comment about Fedora 33 Workstation where the static hostname is set to localhost.localdomain, and got Tilix confused.