Symlinks are not maintained when splitting

[Thomas Meire]

If you work in a directory which is a symlink to another directory and you split the terminal, the new terminal won't have the symlink as cwd, but the target-directory.

Steps to reproduce:
1. create a symlink ~/Desktop/testfolder/ to ~/testfolder/
2. open terminator and cd to ~/Desktop/testfolder/
3. split the terminal. The new terminal is at ~/testfolder/ instead of ~/Desktop/testfolder/

The two paths are actually the same, but it can be a little confusing and irritating (certainly when the symlink is used to hide a long pathname).

[Chris Jones (cmsj)]

Interesting bug. I'm not actually sure if it's possible we can do anything about this - the only way we can maintain cwd from one shell to the next is by inspecting the cwd of the child process of a vte widget and this will give us the absolute path.
Unless there is something I am missing, our only option is to revert to the behaviour of opening with the cwd of the main Terminator process.

[Thomas Meire (blackskad)]

If I'm not mistaken, /proc/pid/cwd will point to ~/Desktop/testfolder/, which in turn points to ~/testfolder/. To resolve the cwd-symlink, we use os.path.realpath. But this function resolves all symlinks it encounters, and will thus resolve the cwd-symlink to ~/testfolder/ instead of ~/Desktop/testfolder/.
So another solution would be to find a function which follows a symlink for only one level (cwd-symlink ->~/Desktop/testfolder/).

[Chris Jones (cmsj)]

Hi

Thomas Meire wrote:
> So another solution would be to find a function which follows a symlink for only one level (cwd-symlink ->~/Desktop/testfolder/).

That's an interesting point, and it makes me wonder why we're
interpreting the contents of /proc/$PID/cwd at all - if we just read
that file in it should have the path you want.

Cheers,
--
Chris Jones

[Chris Jones (cmsj)]

Err, obviously I don't mean read in that file, since it's a symlink. We need to resolve it one step only.

[Chris Jones (cmsj)]

I just did a little experiment and it doesn't look good:

-(cmsj@kodachi)-(/tmp/3)- ls -ld /tmp/3
lrwxrwxrwx 1 cmsj cmsj 1 2008-06-03 10:26 /tmp/3 -> 2
-(cmsj@kodachi)-(/tmp/3)- ls -ld /tmp/2
lrwxrwxrwx 1 cmsj cmsj 1 2008-06-03 10:25 /tmp/2 -> 1
-(cmsj@kodachi)-(/tmp/3)- ls -ld /tmp/1
drwxr-xr-x 2 cmsj cmsj 4096 2008-06-03 10:26 /tmp/1
-(cmsj@kodachi)-(/tmp/3)- ls -ld /proc/$$/cwd
lrwxrwxrwx 1 cmsj cmsj 0 2008-06-03 10:32 /proc/16825/cwd -> /tmp/1
-(cmsj@kodachi)-(/tmp/3)-

[Thomas Hurst (tom.hurst)]

This is impossible to fix on FreeBSD, for much the same reason as it appears to be on Linux; the cwd of the process *is* the target of the symlink, since the symlink isn't a real directory, it just points to one.

On tcsh at least, this is reflected in the prompt since it just uses getcwd(); bash appears to track cwd itself, and thus shows you the symlink name even if the "real" cwd is the target. I would say our behavior in this case isn't really a bug, it's more a shell UI issue. Short of attaching gdb to the shell and ripping out what it thinks the cwd is, or having the prompt command broadcast it over dbus or so, there's not much we can do.

[Wacław Jacek (waclawjacek)]

I would also like to have it fixed. It works in tmux.