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.