Ah hm, I would guess it has something to do with newer vte291 in Fedora 33.

Related github issue: https://github.com/gnunn1/tilix/issues/1954

rishi, do you have any idea what's going wrong here?

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

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?

I changed the component to vte, hope that's allowed.

Tilix uses vte291, moving to there.

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.

Unlike kitty and tilix, splitting functionality still works as expected when using terminator, so it's still somehow possible to remember the previous directory.

For cases where the current working directory isn't getting preserved, what's the output of:
$ echo $PROMPT_COMMAND

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.

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.

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.

> 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).

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.

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

*** Bug 1903092 has been marked as a duplicate of this bug. ***

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.

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.

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

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

This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.