The . entry exists in MS-DOS because it was copied from Unix.
In Unix, it serves the purpose of supplying a name to the current working directory. If we want to traverse the current working directory, we need to pass something to the
DIR *d = opendir(".");
The dot is also useful for executing programs that are in a relative path. For security reasons, relative paths are not included in
PATH by default.
$ cc myprogram.c -o myprogram
file not found: myprogram
PATH searching rule is that if the command name contains no slashes, then
PATH is used, otherwise it is taken as-as. In order to insert a slash into the
myprogram path name, we need to put it in front, and then we need a
., otherwise we have the absolute path
All that still doesn't answer the question of why
. entries have to actually be in the file system. We can guess here that the reasons is a certain elegance: it avoid special cases elsewhere.
Note that in early versions of Unix, it was the
mkdir utility which created both the
.. entries. (Click the link for
mkdir.c source from 1979.) In early Unix, the
mknod system call (familiar for creating character and block special files) also created directories. I.e. nodes in the filesystem tree; hence "make node". The
mkdir program used
mknod to create the directory, and then
link to make the
.. links. Today, making hard links to directories typically is not allowed in Unix-like operating systems, and there is a dedicated
mkdir system call.
Essentially, these were conventions established by user space.
If user space didn't create the
. link, then to have that convention, the kernel's name lookup routine would've had to implement it as a special case, which the designers might have regarded as an inelegant option.
Of course, when non-Unix filesystems are integrated into Unix, they don't necessarily have a dot entry. But their respective filesystem drivers can simulate the presence of that entry to conform to the convention.
It's also noteworthy that the
mkdir.c program is taking advantage of the
. being a prefix of
..; it uses
strcat to add the dots to a path buffer one at a time as it is making the links.
cp path_to_files .
CHDIRmentioned seams to point to MS-DOS - then again the dot entries are of Unix origin, aren't they?
chdir .as the centre of the argument seems a little odd, because it's a no-op function. Command sets abound with effective no-ops:
cat /dev/nul, etc. One useless example does not demonstrate the lack of usefulness.
*-- though it's unclear to me after a quick scan whether this is parsing convention or actual directory entry) -- but no self reference.
cd .actually does have a purpose: it "reconnects" the local filesystem to the remote, while leaving the shell in the same directory. It's useful if you want to keep using a shell instance that has a stale connection.