Почему был выбран для представления текущего каталога и '..' для родительского каталога?

Я сомневаюсь, что Вы собираетесь найти столь же интересный ответ относительно вопроса о тильде!

Я не был там, но.. похож на замещающий знак (...), который имеет смысл в контекстах как cd ../../../there. Кроме того, и особенно смотря на Вас olde клавиатура терминала от случая тильды, с этой целью нет многих имеющих право символов. Вы не должны смещаться для ., также. Это прекрасно.

То, что точечный префикс используется для скрытых файлов, могло бы быть другой причиной. Скрытые файлы не перечислены по умолчанию инструментами такой как ls, таким образом, ни один не чрезвычайно избыточное . и ... Избыточный в том смысле, что нет никакого смысла, рассматривая их наряду с другими файлами - они, конечно, полезны иначе.

Как оказалось, у меня может быть он назад... из Википедии:

Понятие, что имена файлов, которым предшествует a'.', должны быть скрыты, является результатом программной ошибки в первые годы Unix. Когда специальное предложение '.' и '..' записи каталога были добавлены к файловой системе, было решено, чтобы команда ls не отображала их. Однако ls программа была по ошибке записана для исключения любого файла чье имя, запущенное с a'.', а не только названных '.' файлов или '..'.

Это действительно оказывается полезным при программировании; так как система действительно включает. и.. в ответ на readdir() введите команды (и окружите шарики), игнорируя их, и скрытые файлы могут быть выполнены тот же путь.

Другое мнение о том значении использования находится в ссылке для кавычки Википедии. Конечно, целая история могла быть недостоверной..., немного трудно полагать, что, например, Dennis Ritchie, изображенный, просто проверив на первый символ, был бы хорошо.

Я не соглашаюсь с автором vis, было бы лучше поместить скрытые конфигурационные файлы в их собственный каталог, а не дать им универсальный префикс. Префикс намного более гибок, допуская директивы в дереве как .gitignore и .htaccess. Свидетель, что файлы того вида также появляются вместе при лексикографической сортировке - поэтому, возможно, это было нарочно, в конце концов.

^{В основном тот же ответ, что и @Panos в stackoverflow:}

Короче говоря, он произошел от dиdd(каталога dи каталога dкаталога d), которые были созданы пользователями вручную. dстал точкой , а эти .и ..были созданы сначала утилитой mkdir(setuid после того, как связывание каталогов больше не разрешалось простым пользователем ), а затем системный вызов mkdir.

Отрывок из интервью с Кеном Томпсоном(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.