After reading this question Why was '~' chosen to represent the home directory?, next obvious question on my mind was why '.' and '..' was used to represent current directory and parent directory.
It seems so intuitive now, but any particular reason?
I doubt you are going to find as interesting an answer as to the tilde question!
I was not there, but .. is like an ellipsis (...), which makes sense in contexts like cd ../../../there. Also, and especially looking at ye olde terminal keyboard from the tilde case, there are not many eligible characters for this purpose. You don't need to shift for ., either. It's perfect.
The fact that a dot prefix is used for hidden files might be another reason. Hidden files are not listed by default by tools such as ls, so neither are the essentially redundant . and ... Redundant in the sense that there is no point considering them along with other files -- they are certainly useful otherwise.
As it turns out I may have it backwards...from wikipedia:
The notion that filenames preceded by a '.' should be hidden is the result of a software bug in the early days of Unix. When the special '.' and '..' directory entries were added to the filesystem, it was decided that the ls command should not display them. However, the ls program was mistakenly written to exclude any file whose name started with a '.', rather than only files named '.' or '..'.
This does turn out to be useful when programming; since the system does include . and .. in response to readdir() type commands (and shell globs), ignoring them and hidden files can be accomplished the same way.
A different opinion about that use value is in the reference for the wikipedia quote. Of course, the whole story could be apocryphal...it is a little hard to believe that eg, Dennis Ritchie figured just checking for the first character would be okay.
I disagree with the author vis, it would be better to put hidden configuration files in their own directory rather than give them a universal prefix. The prefix is much more flexible, allowing for in-tree directives like .gitignore and .htaccess. Witness that files of that sort also appear together when sorted lexicographically -- so perhaps this was on purpose after all.
Mostly the same answer as @Panos' on stackoverflow:
In short, it evolved from d and dd (the directory and the directory's directory) which were created by users by hand. d became dot, and those . and .. were created first by the mkdir utility (setuid after linking directories was no longer allowed by mere user) and later by the mkdir system call.
Excerpt from an interview with Ken Thompson (1989-09-06):
MSM: But to the user it would look roughly the same as a hierarchy of directories.
Thompson: No, the first one was a DG. In fact, it wasn't even acyclic. If you understand the UNIX file system, it was.... there was the I-list, which is a definition of all the files on the system. And then some of those files, were directories which just contained name and I-number. There's nothing in there that constrains it to a tree. So it was not in fact, not hierarchical at all.
MSM: I see.
Thompson: And we did not restrain it to a tree. We were experimenting with various topologies. What we ended up doing is turning into concrete and forcing the topologies that in fact were the topologies that came by convention from that system. The... Every time we made a directory, by convention we put it in another directory called directory - directory, which was dd. Its name was dd and that all the users directories and in fact most other directories, users maintain their own directory systems, had pointers back to dd, and dd got shortened into dot-dot, and dd was for directory-directory. It was the place back to where you could to get to all the other directories in the system to maintain this spaghetti bowl. So, I mean this tuff in various forms, which was strictly convention in this DG implementation of just random set of directories and files got forced into a typology that we maintained. When we started writing things like file systems checking programs and stuff, the locking of the spaghetti bowl directories and finding of disjointed things, I mean you'd dissever something and never get it back, because you know you'd lost it. Those problems became close to insurmountable, and so in the next implementation we forced a typology stronger than that.
