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
Improve this question
0

3 Answers 3

Reset to default
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
Improve this answer
2
  • 1
    That makes perfect sense. It is kind of existential :).
    – user160910
    Mar 21, 2013 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, 2021 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.

Improve this answer
5
  • 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, 2013 at 20:42
  • Good point, I'm sure this whole premise can be a little confusing to some!
    – David Houde
    Mar 21, 2013 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, 2013 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, 2013 at 20:58
  • 1
    @vonbrand But the explanation is correct iff your shell acts this way. YSMV (Your Shell May Vary)
    – bonsaiviking
    Mar 21, 2013 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)

Improve this answer

You must log in to answer this question.