When ".." isn't the same? (not a problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]




> -----Original Message-----
> From: centos-bounces@xxxxxxxxxx [mailto:centos-bounces@xxxxxxxxxx] On
> Behalf Of Ulrik S. Kofod
> Sent: Friday, May 13, 2005 2:25 AM
> To: centos@xxxxxxxxxx
> Subject:  When ".." isn't the same? (not a problem
> 
> I don't understand why ".." isn't working the same way for "ls" and
"cd"
> when inside
> a symbolic link. The reason I ask is that I made a link to a directory
> with some
> scripts that saves output in "../output.txt" and I could not find the
> output until I
> found that ".." isn't the directory you see when you do a $pwd. I
solved
> the problem
> by making a directory and then make a link to each script in there.
> 
> I would just like to know:
> 1) if there is a good reason to this behaviour.
> 2) if there is a rule, so you know when ".." is level up from $ pwd
and
> when it is
> one level up from the link target.
> 3) if there is an alternativ way to point to the parent directory.
> 

I believe I understand what you're describing and it's been a long time
since I've had this 'issue' but if I remember correctly, it's a function
of your shell, which I believe is going to be bash. It tries to be
intelligent about its symlink handling. It remembers the cd path you
used to get to that symlink and 'cd ..' sends you back the same way you
got in. It basically treats symlinks as real directories, not pointers.
This can be very useful but it can also be annoying. I'll bet if you use
tcsh, which uses a more literal interpretation of the file-structure, it
would work as you expect. I wasn't ever interested in it enough to see
if it could be disabled in bash.

--
Marc

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux