0

NOTE: This behaviour is observed via remote access using SSH.

I noticed that if I have moved into a directory using a symlink that I cannot use the .. entry in the directory listing to move back into the parent and then into subsequent directories. For example:

/DirA/SymLinkToDirB
/DirA/SomeOtherFile.txt
/DirA/DirB
/DriA/DirC

/DirA/DirB/someFile.txt

If I was currently in DirA and issued the following command: cd SymLinkToDirB then a subsequent pwd would resolve /DirA/DirB, as expected. However, the following would not work if I was currently in DirB via the symLink.

vim ../SomeOtherFile.txt, or even cd ../DirC

Further, hitting tab while using cd would normally list the directories that a user may traverse to. However, again, this behaviour one expects and observes on a local machine also does not work over SSH.

However, the following does work if we are already in DirB having gotten there via the symlink: cd ../SymLinkToDirB/, which is a rather useless action. It seems as if the symlink resides within a directory (its parent) all its own.

No doubt this has to do with how symlinks are handled in SSH What is the mechanism through which symlinks are handled via SSH that provides this behaviour?

Kenster
  • 7,483
  • 2
  • 32
  • 44
sherrellbc
  • 719
  • 2
  • 15
  • 27
  • Are you asking what was in the developer's mind? – rfportilla Jun 24 '15 at 14:24
  • I cannot reproduce what you're seeing. Are you sure you created a symbolic link (using `ln -s`)? – Ash Jun 24 '15 at 14:27
  • @rfportilla, A terrible reason to downvote. No, if you read the last two blocks of text I lay it out pretty clearly. I assert it must have to do with how the symlinks are handled in Linux and ask for what reason it does not work as expected. An explanation as to how symlinks work would give the answer directly. – sherrellbc Jun 24 '15 at 14:27
  • @Ash, yep. That's the only method I know to create them actually. In this case it would be something like `ln -s /DirA/DirB/ /DirA` to generate a symlink to `DirB` and place it inside `DirA`. – sherrellbc Jun 24 '15 at 14:30
  • I will be happy to remove the down vote if you update this post to reflect that clearly. The question I see in this post is in the last sentence: "Why do these commands not work as expected?" I don't know your expectations nor do I know what was in the developers' minds when they created the functionality. – rfportilla Jun 24 '15 at 14:30
  • @Ash, the majority of my work is done via SSH so I did not take note of the fact that on my local machine such behaviour is not observed. – sherrellbc Jun 24 '15 at 14:38
  • @rfportilla, Agreed. I could have outlined the question more explicitly. I added a new note to the post as well. Locally this all performs as expected, but the things I note above are true only if a user is interacting remotely via SSH as I was. – sherrellbc Jun 24 '15 at 14:42
  • np, fixed my vote. ;-) – rfportilla Jun 24 '15 at 14:43
  • What shell are you using on that remote machine? In some shells like `tcsh` one can customize how the $cwd behaves when it comes to symlinks (on which child processes rely when using relative paths). – Dan Cornilescu Jun 25 '15 at 02:07
  • Symlinks are not "handled in SSH". SSH gives you access to remote tools including shells. The shell you use handles `cd` and tab completion. Please see [this](https://superuser.com/a/1217241/432690) and [this](https://superuser.com/a/1312268/432690). – Kamil Maciorowski Mar 10 '19 at 00:03

1 Answers1

1

The cd command is trying to be smart, and remember specifically how you got to the directory you are currently in, and assumes that you want to follow the same path out again.

However, once you are in the directory, other commands (like vim) will see the existing .. directory and follow it through the real file system.

What I will do sometimes is cd symlinktoDirB/../DirB/.. . Using the extra set of ..s will force cd to see the real file system path and follow it.

hymie
  • 1,256
  • 11
  • 18