The reason for existence and the use of .
and ..
.
and ..
are entries which are normally present in every directory. Their meaning is not related to the working directory of a process (like shell) but to the directory the entry is in.
..
provides two-way linking of the directory tree structure while .
is a convenient name for referring to the directory itself. The path directory/.
is the same as directory
. Theoretically an empty string could have been chosen to refer to the directory itself but in fact it is not like that: ls ''
does not work and the meaning of an empty string would be ambiguous because at the beginning of the a path it refers to the root directory already: Would /file1
mean file1
in the root directory or file1
in the current working directory?
As thomasrutter showed it is important that as normal directory entries you can use .
and ..
in a path. For example ./-filename
could be used to avoid interpreting of the dash character -
as an introduction of command line options. The path directory1/../directory2
in effect is the same as ./directory2
which is the same as directory2
.
Why are .
and ..
hidden?
File (and directory) names with .
at the beginning are by convention hidden in Unix-like systems so by default most of tools will not show the .
and ..
directories. This is useful because we already know the .
and ..
are normally present in every directory.
The command ls -a
shows all the directory entries. In Nautilus Ctrl+H turns displaying of the hidden entries on but with exception of .
and ..
because they are normally not very useful in a graphical file manager. For similar behaviour on the command line you can use ls -A
.
Are .
and ..
real directory entries?
Yes, in the commonly used file system they are. (as Jonathan Leffler reminded) How can we check that?
# prepare the directory
cd /tmp ; mkdir testdir1
# test 1
ls -lid testdir1 testdir1/. testdir1/..
1179767 drwxrwxr-x 2 pabouk pabouk 4096 Nov 12 11:52 testdir1
1179767 drwxrwxr-x 2 pabouk pabouk 4096 Nov 12 11:52 testdir1/.
1179650 drwxrwxrwt 14 root root 4096 Nov 12 15:17 testdir1/..
The inode number (1st column) referring to the data structure of the directory/file itself is the same for the same directory testdir1
and testdir1/.
. The link count (3rd column) showing the number of the directory entries referring to the inode (directory/file) is 2 right after creating the directory because there is testdir1
in /tmp
and .
in /tmp/testdir1
. The inode of /tmp/testdir1/..
(/tmp
) has 14 links because it has 12 subdirectories containing ..
+ the 2 entries as every directory.
# test 2
touch testdir1/tesfile1 # to have a regular file too
debugfs /dev/sda2 -R 'ls -l /tmp/testdir1' | cat
debugfs 1.42.12 (29-Aug-2014)
1179767 40775 (2) 1000 1000 4096 12-Nov-2015 11:52 .
1179650 41777 (2) 0 0 4096 12-Nov-2015 15:46 ..
1179771 100664 (1) 1000 1000 0 12-Nov-2015 11:52 tesfile1
The utility debugfs
reads the ext2 (and newer) file system data directly from the disk sectors (bypassing the file system in the Linux kernel).
# test 3
debugfs /dev/sda2 -R 'dump /tmp/testdir1 '>(od -tax1)
debugfs 1.42.12 (29-Aug-2014)
0000000 w nul dc2 nul ff nul soh stx . nul nul nul stx nul dc2 nul
77 00 12 00 0c 00 01 02 2e 00 00 00 02 00 12 00
0000020 ff nul stx stx . . nul nul { nul dc2 nul h si bs soh
0c 00 02 02 2e 2e 00 00 7b 00 12 00 e8 0f 08 01
0000040 t e s f i l e 1 s o c k e t nul nul
74 65 73 66 69 6c 65 31 73 6f 63 6b 65 74 00 00
0000060 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0010000
If you do not believe the directory listing of debugfs
you can examine the raw dump of the directory and check that the .
and ..
entries are really there.
.
and..
exist?.
and..
exist in all directories. If you want to see all files in a directory except those, usels -A
instead ofls -a
.