$> ls ../../../../..

Doesn't give me the same result as

$> cd ../../../../..
$> ls

Why? Something with links? What's going on?

[ johanrj@jamin ] ~/XXX/broadcom/asuswrt/release/src-rt-6.x/linux/linux-2.6/drivers/net/phy/WRT/openwrt-git-8.09.2/package/swconfig/src  
$> ls ../../../../..  
9145-D5B0  asuswrt  BCM53125  bcm_switch  jrj  Packages  workspace  

[ johanrj@jamin ] ~/XXX/broadcom/asuswrt/release/src-rt-6.x/linux/linux-2.6/drivers/net/phy/WRT/openwrt-git-8.09.2/package/swconfig/src  
$> cd ../../../../..  

[ johanrj@jamin ] ~/XXX/broadcom/asuswrt/release/src-rt-6.x/linux/linux-2.6/drivers/net/phy  
$> ls  
adm6996.c   cicada.c   libphy.ko     lxt.c             mdio-boardinfo.h  mdio_bus.o      phy_device.c  smsc.c           swconfig.mod.c  WRT
adm6996.h   davicom.c  libphy.mod.c  Makefile          mdio_bus.c        Module.symvers  phy_device.o  swconfig.c       swconfig.mod.o
b53         fixed.c    libphy.mod.o  marvell.c         mdio_bus.c.orig   phy.c           phy.o         swconfig.ko      swconfig.o
broadcom.c  Kconfig    libphy.o      mdio-boardinfo.c  mdio_bus.c.rej    phy.c.orig      qsemi.c       swconfig_leds.c  vitesse.c
  • Yes, probably it is due to symbolic links. Try to use cd -P which means "Handle the operand dot-dot physically", but details may depend on your particular shell (bash/zsh/...) because cd is a built-in command. – jimmij Nov 12 '14 at 8:29

Yes, your shell tries to be smart on changing to a symlink directory:

$ mkdir a
$ ln -s a b
$ cd b
$ pwd
$ pwd -P

After changing to symlink b your shell pretends you are really in "directory" b but instead the symlink sent you to directory a.

See help pwd:

  -P        print the physical directory, without any symbolic links

External commands (like ls) will always use the physical path, but shell builtins default to use the virtual symlink path.

The cd command is a shell builtin and will default to interpreting cd .. as "leave the current symlink", instead of "use the physical parent". But you can change that behavior. help cd says:

   -P      use the physical directory structure without following symbolic
           links: resolve symbolic links in DIR before processing instances
  • Thx! But what about symlinks when using make to compile C code. It seems I might have a problem there. Do you know anything about that? – JohnyTex Nov 12 '14 at 9:51
  • 1
    Only builtins of the shell are able to use those virtual paths. All other commands like make will use the real physical structure. – michas Nov 12 '14 at 10:27

You can get the real path, with links resolved using realpath and compare the output

realpath ../../../../..
cd ../../../../..
realpath .

On my system:

~/shared $ realpath ..
~/shared $ cd ..
~ $ realpath .
  • $> realpath ../../../../.. /home/johanrj/XXX/broadcom/asuswrt/release/src-rt $> cd ../../../../.. $> realpath . /home/johanrj/XXX/broadcom/asuswrt/release/src-rt-6.x – JohnyTex Nov 12 '14 at 9:03
  • 1
    @JohnyTex those look different to me, so you have a link in there somewhere – Anthon Nov 12 '14 at 9:05
  • Yes they are different, and thanks for the tip, but how come a link evaluates to different paths for ls and cd? Shouldn't they evaluate to the same path even with links? – JohnyTex Nov 12 '14 at 9:37
  • 1
    @JohnyTex this is some smart handling of the shell, so that when you cd to a path, it looks like you actually got where you specified you wanted to go, even if there was a link in the path and you arrived somewhere else on disc. The shell keeps an internal path, which is different from asking to look at the current position on the disc and then go a few directories up. – Anthon Nov 12 '14 at 10:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.