5

This is more of a curiosity, but I noticed /etc/httpd/logs is symlinked to /var/log/httpd, but when I am inside of /etc/httpd/logs and I do ls -la I see:

drwx------ 2 root root    4096 Mar 21 14:58 .
drwxr-xr-x 9 root root    4096 Mar 17 03:10 ..

Why doesn't the . entry show lrwx....?

But when I go to /etc/httpd and do ls -la I see: 

lrwxrwxrwx 1 root root   19 Mar  4 17:12 logs -> ../../var/log/httpd
jscott
  • 24,204
  • 8
  • 77
  • 99

3 Answers3

8

May I answer with a question? Assuming you're on a RedHat/CentOS install here...

ls /etc/httpd/
  # should return something like:
  # conf  conf.d  logs  modules  run
cd /etc/httpd/logs/
  # Why does this next command fail?
ls ../conf
  # ls: cannot access ../conf: No such file or directory
  # But this next command works?
cd ../conf

The short answer is when you're "inside" /etc/httpd/logs (the symlink) you're actually inside /var/log/httpd, which is a directory.

cd /etc/httpd/logs/
pwd
  # /etc/httpd/logs
pwd -P
  # /var/log/httpd
jscott
  • 24,204
  • 8
  • 77
  • 99
  • 1
    That makes perfect sense. It is kind of existential :). –  Mar 21 '13 at 20:37
  • This answered my question (via Google), of why `ls -la /some/symlinked/dir` was not showing the files contained! I just `cd` to that directory, then it worked. – Robert Dundon Sep 10 '21 at 18:33
4

. indicates the current directory. Once you cd to a symlink, you are in the destination directory. What you are seeing is not an error, or a problem of any kind. This is how symlinks work in unix systems. If you want to see the symlink when you list files, then stay in the parent directory where the actual symlink exists.

Nakilon
  • 128
  • 1
  • 1
  • 8
David Houde
  • 3,160
  • 1
  • 15
  • 19
  • 1
    Some shells do keep the history (i.e., how did I land here) around, so if you do `cd symlink; cd ..` you are back where you were. – vonbrand Mar 21 '13 at 20:42
  • Good point, I'm sure this whole premise can be a little confusing to some! – David Houde Mar 21 '13 at 20:44
  • 2
    @vonbrand Because cd is a shell built-in, `..` refers to the shell's concept of "up," based on your "directory history." `ls` is a separate binary, so it interprets `..` to be the directory entry `..` according to the filesystem, which has no way to know it has been symlinked from elsewhere. – bonsaiviking Mar 21 '13 at 20:52
  • @bonsaiviking, no. The shell could just not care and change directory as told (the Bourne and C shell did). Remembering where we come from is extra work to help (un)confuse the user. – vonbrand Mar 21 '13 at 20:58
  • 1
    @vonbrand But the explanation is correct iff your shell acts this way. YSMV (Your Shell May Vary) – bonsaiviking Mar 21 '13 at 21:19
1

By default, cd is going to "follow" the symlink, but it then sets the PWD systems variable with /etc/httpd/logs. So that way when you do cd .. it uses the PWD variable for reference. ls won't. It grabs the physical location of where you're at (/var/log/httpd), just like /bin/pwd but shell builtin pwd uses the $PWD variable.

So when you cd into /etc/httpd/logs, you actually go to /var/log/httpd. Thats why when you do ls -la, you see . as a directory and not a symlink. Then when you use cd to back out, it remembers that you were in /etc/httpd and uses that as the reference.

If you do cd -P /etc/httpd/logs, with -P meaning 'physical', you can see that cd sets PWD to /var/log/httpd.

(sorry, my answer was a mix of your question and jscotts question)

Safado
  • 4,726
  • 7
  • 35
  • 53