How do pwd and . determine the current path differently

directorypwd

Is it mainly because pwd is not a builtin, while . is builtin to the bash shell?

For example, they differ in the following example:

/tmp/ttt$ mv ../ttt ../tttt
/tmp/ttt$ pwd
/tmp/ttt
/tmp/ttt$ cd .
/tmp/tttt$

Best Answer

. is not a bash (or any other shell) built-in. Each and every directory has entries . and .. in it. You can verify by cd'ing to some arbitrary directory and doing ls -lia . You will see . and .. entries. I had you use the '-i' flag on ls to get inode numbers: note them for . and ... Go up a directory, but doing cd .. or cd /something/soemthingelse/whatever. Do ls -lia again. Notice that the inode number of . is identical to that of .. in your first listing. Every directory has directories in it when created, named "." and "..". The "." entry has the same inode number as the directory's name does in its parent directory. The ".." entry is always the parent directory. If you do ls -li / you will see that "." and ".." have the same value.

This convention eliminates the need for special case code to reference the current directory: it's always named ".". It eliminates the need for special case code to "go up one directory": it's always "..". The only special cases are the root directory, and network-mounted filesystems. The filesystem root has "." and ".." with the same inode number, not different. Network-mounted filesystems have a discontinuity in inode numbers at the mount point, and behavior depends on what the remote filesystem is, and what protocol is used to mount it.

As far as the change in prompt, when you invoked mv ../ttt ../tttt, you actually renamed your shell's working directory. You didn't invoke a shell command that checks working directory until you did cd ., so the intervening pwd reports the old name, /tmp/tt.

Related Solutions

Bash – symbolic link to a directory and relative path

I don't think you can do this. Shells nowadays keep track of how they got where they are, they keep track of current working directory by name, rather than just relying on file system and OS to keep it. That means the built-in cd can go "back up" the symbolic link, rather than just following ".." chains directly.

But when you run ls ../foo, ls isn't aware that the shell got to a directory by following symbolic links. ls will do a stat() on "../foo". The ".." part comes from the current directory, which has only a single ".." entry for it's parent. The whole symbolic link thing doesn't change the way directories have a single "." and a single ".." entry. Symbolic links let the kernel insert an extra layer of indirection into file paths. When you pass "../whatever" to open() or stat(), the kernel just uses the current working directory of the process doing the call to figure out which single directory is named by "..".

“ls $PWD” and “ls .” get different files, strange caching perhaps

This can happen if the current directory is renamed or moved while you're in it.

For example:

$ mkdir /tmp/X
$ cd /tmp/X
$ mkdir Y Z
$ cd Y
$ touch a b c d e f
$ mv ../Y ../A
$ mv ../Z ../Y
$ echo $PWD
/tmp/X/Y
$ ls
a  b  c  d  e  f
$ ls $PWD
$

You can spot the difference in looking at the inode number of the directory:

$ ls -ldi . $PWD
26871815 drwxr-xr-x 2 sweh sweh 4096 Jul 12 17:27 ./
26872035 drwxr-xr-x 2 sweh sweh 4096 Jul 12 17:27 /tmp/X/Y/

You can also detect this because /bin/pwd returns a different value

$ /bin/pwd
/tmp/X/A
$ echo $PWD
/tmp/X/Y

Basically, $PWD is just where the shell thinks you are, not necessarily where you really are :-)

Best Answer

Related Solutions

Bash – symbolic link to a directory and relative path

“ls $PWD” and “ls .” get different files, strange caching perhaps

Related Question