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/
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.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
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 bug 1893417 , 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 comment 18 about Fedora 33 Workstation where the static hostname is set to localhost.localdomain, and got Tilix confused.
*** This bug has been marked as a duplicate of bug 1893417 ***