iTerm2 behaviour when splitting the terminal on a symlinked path

[David Martin]

Hello,

most of the time I work on directories that are followed from symbolic
links. I'm using the "Reuse previous session's directory" option and
when I'm opening a new tab or splitting a current tab on a path that
follows a symlink, the new window will open on the absolute path
instead of the previous symlinked one.

Is this behaviour intended? I think it should not be. Any idea how to fix it?

My setup:
Mac OS X 10.8
iTerm2 Build 1.0.0.20130319
"Reuse previous session's directory" is ticked

Simple steps to reproduce it:

$ mkdir -p test1/test2
$ mkdir test3
$ cd test1/test2
$ ln -s ../../test3
$ cd test3

Now, at this point 'pwd' prints something like:
$ pwd
/Users/davidm/Documents/test1/test2/test3

Now open a new tab or split the current window and print pwd again:
$ pwd
/Users/davidm/Documents/test3

Ideally, the new session should be started on the same path as the old one.

Thank you in advance! Cheers,

David

[George Nachman]

Unfortunately, it's impossible to get the current directory of the shell including symlinks (at least as far as I know). Only the shell knows that you're in a directory from a symlink, but we get the path from the OS, which only knows about the "real" directory.

--
You received this message because you are subscribed to the Google Groups "iterm2-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iterm2-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Rick Hornsby]

I might be wrong, but from what I understand unless you de-reference the symlink, the *NIX OS will tell you the directory you're in is the path as followed by the symlink.  A symlink is not a shell function, it is an OS function?

In that sense, Python, perl, etc (and anything you could come up with) don't need special code to handle a symlink - the OS abstracts it for the userland process - a symlink is presented as a file.  If the process wishes, it can ask the OS "is this a symlink and if so, give me the dereferenced path."

Maybe directories are different but in the case of a symlink

/usr/lib/foo.so -> /usr/lib/foo.so.1

foo.so is treated exactly and presented to a userland process the same as if they had asked for foo.so.1 - that is, the process believes that foo.so is the library and knows nothing about foo.so.1.

It feels like somewhere in the process here of determining the cwd, maybe the symlink is getting de-ref'd for some reason?



Sent from my iPad

[Scott Gifford]

On Thu, May 9, 2013 at 7:39 PM, Rick Hornsby <richard...@gmail.com> wrote:

[ ... ]

It feels like somewhere in the process here of determining the cwd, maybe the symlink is getting de-ref'd for some reason?

The operating system dereferences the symlink automatically when you call chdir(2), then forgets about the symlink that got you there.  Your shell keeps track of it for your convenience.

Generally the shell keeps the current working directory including any symlinks followed to get there in an environment variable, so you might be able to pass that up to iTerm with some clever escape sequence, but the details would require some thinking.

-----Scott.

[George Nachman]

That's a more eloquent version of what I was trying to say :)

[Josh Moore]

On my machine, pwd -L prints the path without dereferencing the symlinks.