Bug 1888447 - Loses track of the current working directory because it doesn't know about static and transient hostnames
Summary: Loses track of the current working directory because it doesn't know about st...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: tilix
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kalev Lember
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1903092 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-14 21:24 UTC by smurfendrek123
Modified: 2021-08-10 12:48 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github gnunn1 tilix issues 1954 0 None open Fedora 33 : vte configuration fixes no longer work. 2021-02-06 00:15:12 UTC

Description smurfendrek123 2020-10-14 21:24:25 UTC
When creating a new tile in tilix, the working directory is ~ instead of the directory of the previously focused tile. This used to work correctly on fedora 32.

I have tried both fixes outlined here: https://gnunn1.github.io/tilix-web/manual/vteconfig/

Comment 1 Kalev Lember 2020-10-14 21:52:10 UTC
Ah hm, I would guess it has something to do with newer vte291 in Fedora 33.

Comment 2 smurfendrek123 2020-10-28 18:51:30 UTC
Related github issue: https://github.com/gnunn1/tilix/issues/1954

Comment 3 Kalev Lember 2020-10-28 20:19:18 UTC
rishi, do you have any idea what's going wrong here?

Comment 4 smurfendrek123 2020-11-02 11:12:59 UTC
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

Comment 5 smurfendrek123 2020-11-02 17:51:40 UTC
This is also broken in kitty, so should this bug be filed against vte.sh instead of tilix? Can this report be changed, or do i need to make a new one?

Comment 6 smurfendrek123 2020-11-02 17:53:01 UTC
I changed the component to vte, hope that's allowed.

Comment 7 Kalev Lember 2020-11-02 18:58:35 UTC
Tilix uses vte291, moving to there.

Comment 8 Milan Zink 2020-11-03 20:21:34 UTC
Fish shell seems to work fine in tilix. Gnome-terminal new tab also switches to working dir, not ~.

Tilix reports vte config issues even if /etc/profile.d/vte.sh is sourced in .bashrc.

Comment 9 smurfendrek123 2020-11-11 15:16:30 UTC
Unlike kitty and tilix, splitting functionality still works as expected when using terminator, so it's still somehow possible to remember the previous directory.

Comment 10 Debarshi Ray 2020-11-11 16:50:44 UTC
For cases where the current working directory isn't getting preserved, what's the output of:
$ echo $PROMPT_COMMAND

Comment 11 smurfendrek123 2020-11-11 21:19:27 UTC
From tilix:

~ : echo $PROMPT_COMMAND 
__vte_prompt_command


Note that despite remembering the directory working correctly in terminator, the output of 'echo $PROMPT_COMMAND' is exactly the same in terminator.

Comment 12 Milan Zink 2020-11-12 09:38:03 UTC
This is very weird.. I've installed a new F33 virtual machine (+ dnf update) and it works out-of-the box in all mentioned terminal apps - tilix, gnome-terminal, terminator... 

echo $PROMPT_COMMAND gives the same results __vte_prompt_command.

/etc/profile.d/vte.sh seems to be sourced by default. No need to add it in .bashrc

Not able to reproduce it again.

Comment 13 Debarshi Ray 2020-11-12 17:35:16 UTC
I just installed Tilix on a freshly installed Fedora 33.

When I first started it, I got the dialog warning about the configuration problem, but after I clicked it away, Tilix was still able to preserve the current working directory. Then, once I closed Tilix, subsequent instances of the application don't show me the warning anymore, even though I didn't do anything to fix it.

Looking at tilix/source/gx/tilix/terminal/terminal.d, I see this condition for showing the warning dialog:
    if (terminalInitialized
        && tilix.testVTEConfig()
        && gst.currentLocalDirectory.length == 0
        && _overrideCommand.length == 0) {
        ...
        ...
        ...
    }

It seems to that the "gst.currentLocalDirectory.length == 0" is the main condition here, because the rest are just checking the state of the application so that the warning is shown only once during the lifetime of the application and at the right moment. However, it's not obvious to me that the condition is correct. Especially, since I received what seemed like a spurious warning.

I am also beginning to wonder if it could actually be a Tilix bug. I personally use GNOME Terminal, and I haven't hit any instance of the current working directory not being preserved, and it also looks like other VTE-based applications are working as expected.

Maybe Gerald would be able to shed some light on this, because my knowledge of D is zero.

Comment 14 smurfendrek123 2020-11-12 19:25:09 UTC
> I am also beginning to wonder if it could actually be a Tilix bug.

This could certainly be possible, but note that it is also broken in kitty (if correctly configured Kitty that is).

Comment 15 Gerald Nunn 2020-11-12 19:40:54 UTC
To preserve the working directory VTE requires that you have vte.sh hooked into bash either through your profile or some other mechanism. Not all Linux distros include vte.sh by default with Ubuntu being one of the main PAST offenders so this detection was an attempt on my part to proactively notify the user. It's not 100% accurate hence why there is a checkbox to ignore it.

In general if gnome-terminal works with regards to preserving the working directory then Tilix should work as well.

Note also I am no longer actively maintaining Tilix due to my other work commitments at Red Hat.

Comment 16 Milan Zink 2020-11-19 10:33:59 UTC
Hi All,

the problem is with hostname. Please check:

* https://github.com/gnunn1/tilix/issues/1954#issuecomment-730191381
* https://github.com/gnunn1/tilix/issues/1954#issuecomment-730279428

Comment 17 Kalev Lember 2020-12-01 11:32:07 UTC
*** Bug 1903092 has been marked as a duplicate of this bug. ***

Comment 18 Debarshi Ray 2021-05-20 23:19:37 UTC
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.

Comment 19 Debarshi Ray 2021-05-21 22:52:20 UTC
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.

Comment 20 Debarshi Ray 2021-05-21 22:53:12 UTC
GNOME Terminal doesn't try to differentiate between local and remote hosts, which is why it doesn't hit this problem.

Comment 21 Petr Sklenar 2021-08-02 11:08:35 UTC
as workaround I added into
/etc/profile.d/vte.sh

this:

HOSTNAME=$(/usr/bin/hostnamectl --static 2>/dev/null) || \
HOSTNAME=$(/usr/bin/hostname 2>/dev/null) || \
HOSTNAME=$(/usr/bin/uname -n)


and it seems to be working fine

Comment 22 Ben Cotton 2021-08-10 12:48:43 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.


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