Почему текущий каталог в команде ls определяется как связанный с самим собой?

Я рекомендую вам прочитать Что такое каталоги, если все в Linux является файлом? для более глубокого знания структуры каталогов, истории и терминологии того, как работают каталоги и их элементов (inode, dirent структура и т. д.), хотя это не требуется для этого вопроса.

Что такое точка '.' и точка-точка '..' каталоги?

Смотря на format of directories Страница справочника издателя руководства UNIX 1971 года, мы видим, что . а также .. были уже там

По соглашению, первые две записи в каждом каталоге предназначены для "." а также "..". Первый - это запись для самого каталога.

Что касается их значения, ответ можно найти на ответе Паноса. Кен Томпсон объяснил, как .. произошло в интервью 1989 года:

Каждый раз, когда мы делали каталог, мы условно помещали его в другой каталог, называемый каталог - каталог, который был dd. Его имя было dd и что все пользовательские каталоги и фактически большинство других каталогов, пользователи поддерживают свои собственные системы каталогов, имеют указатели на dd, а dd сокращен до "dot-dot", а dd предназначен для directory-directory. Это было то место, куда вы могли попасть во все другие каталоги системы, чтобы поддерживать миску спагетти.

Естественно, . как вы можете догадаться расшифровывается как d или не хватает directory, Такой каталог сам по себе имеет тот же номер инода, что и фактическое имя каталога. Теперь это еще не объясняет, почему каталог . связано с собой, но у меня есть пара идей.

0. Unix Философия:

В книге 1996 года "Внутренние органы UNIX: новые границы" Уреша Вахалии в главе 8 на странице 222 говорится:

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

Учитывая, что каталог - это просто специальный файл, нам нужно постоянное относительное имя файла для ссылки на сам каталог, и это будет специальное имя файла ., который эволюционировал из d, который был сокращен для каталога.

1. Технические преимущества

Основное преимущество, которое я могу придумать, заключается в том, что система упрощает поиск инода и, следовательно, информацию метаданных. Поскольку в каталоге уже есть запись, содержащая . с тем же индексом нет необходимости запрашивать полный путь. То же самое касается программирования. Рассмотрим очень простую реализацию ls, Там я использую getcwd() функция, чтобы получить текущий рабочий путь каталога, а затем передать его opendir(), Или я мог бы выбросить getcwd() и просто использовать opendir('.') непосредственно. Во времена старых терминалов PDP-11, где объем памяти составлял несколько килобайт, экономия на служебных вызовах системного вызова имела решающее значение.

2. Удобство для пользователя:

Рассмотрим следующий пример:

mv ../filename.txt .

В презентации Хендрика Яна Томассена было упомянуто, что оригинальные команды Unix были короткими из-за того, что старые клавиши терминала были трудны для нажатия, поэтому было физическим усилием фактически вводить команды весь день. Если вы углубились в дерево каталогов, перепечатка полного пути текущего рабочего каталога будет утомительной. Конечно, mv может быть реализовано с предположением, что, когда мы делаем mv <file> мы подразумеваем пункт назначения как "текущий рабочий каталог". Я могу только догадываться, почему mv <original> <new> преобладал, возможно, из-за влияния других языков программирования того времени.

3. Улучшение над МУЛЬТИКОЙ:

^{Примечание: я никогда не работал над MULTICS, поэтому он основан только на чтении онлайн-источников.}

В соответствии с руководством MULTICS 1986 года по именам путей:

Относительный путь может начинаться с одного или нескольких символов меньше ("<").

> символ используется в MULTICS в качестве разделителя пути (например, / в Linux). Возможно, это может выглядеть запутанным. Таким образом, ./ когда ссылка на команду, возможно, яснее - мы ссылаемся на имя файла, которое находится в текущем рабочем каталоге.

Это может быть полезно для других команд. Хорошо известно, как создать файл в Unix / Linux: touch ./file, На MULTICS, согласно swenson.org, это делается через an или же add_name команда:

cd foo
r 18:03 0.041 1

an foo bar
r 18:03 0.077 3

ls foo

Directories = 1.

sma  foo
       bar

r 18:03 0.065 0

С другой стороны, есть очевидное сходство, когда дело доходит до ..: перемещение по одному каталогу осуществляется через cwd <<,

4. Ссылка на исполняемые файлы

Если вы запускаете сценарии ежедневно, вы хорошо знаете ./script.sh синтаксис. Причина этого проста: оболочка работает так, что ищет исполняемые файлы в PATH переменная, поэтому, когда вы предоставляете ./ это не должно смотреть нигде. Магия PATH переменная - это то, что заставляет вас использовать echo вместо /bin/echo или другие очень длинные пути. Теперь скажем, у вас этого нет script.sh на вашем пути, и он там в вашем текущем рабочем каталоге. Чем вы сейчас занимаетесь? Тип /very/long/path/to/the/executable/this/typing/gets/exhausting/on/PDP-11/finally/script.sh? Это отбросит всю концепцию простоты Unix! Итак, возвращаясь к философии Unix, она также согласуется с принципом элегантного дизайна / простоты.

Конечно, некоторые люди хотят добавить . в PATH, но на самом деле это очень плохая практика, так что не делайте этого.

примечание: особый случай .. а также . указывая на то же самое, это индекс 2 - / dir, и это имеет смысл, поскольку это самая высокая точка в дереве каталогов. Конечно, .. NULL также может работать, но более элегантно / сам.

Примечание о количестве ссылок и жестких ссылках каталогов

Как правильно указал Жиль (на что ссылается Джордж Удосен), счетчик ссылок для каталога начинается с 2 (.. для родительского каталога и .), со всей дополнительной ссылкой, являющейся подкаталогом:

# new directory has link count of 2
$ stat --format=%h .
2
# Adding subdirectories increases link count
$ mkdir subdir1
$ stat --format=%h .
3
$ mkdir subdir2
$ stat --format=%h .
4
# Adding files doesn't make difference
$ cp /etc/passwd passwd.copy
$ stat --format=%h .
4
# Count of links for root
$ stat --format=%h /
25
# Count of subdirectories, minus .
$ find / -maxdepth 1 -type d | wc -l
24

Интуитивно понятно, что ссылки на каталоги являются только подкаталогами - имеет смысл, поскольку жесткие ссылки имеют то же время, что и исходный файл. За исключением того, что это не совсем жесткие ссылки - жесткие ссылки создают имя файла, которое указывает на те же данные. По этому определению жесткая ссылка на каталог будет содержать те же данные, т.е. содержать одинаковый список файлов. Это может привести к зацикливанию в файловой системе или множеству потерянных файлов, если будут удалены все жесткие ссылки на каталог. По этой причине создание жестких ссылок для каталогов недопустимо, и если использовать фразу Жиля из другого вопроса (который я рекомендую вам прочитать) "...[на самом деле, многие файловые системы имеют жесткие ссылки на каталоги, но только в очень дисциплинированный способ..."и это особые случаи . а также .. каталоги.

Теперь возникает вопрос: что на самом деле означает "ссылки" в контексте каталогов? TL;DR: структура каталогов является деревом, и здесь Ссылки означают количество дочерних узлов для каждого элемента дерева (с каждым листом или каталогом без подкаталогов, имеющим только 2 ссылки). В частности, ext3 и ext4 используют HTree, а xfs использует дерево B+

Заключение

В конце концов, причина, почему . связано с собой просто потому, что это хороший дизайн. Первоначальные авторы Unix, возможно, работали с технологическими ограничениями своего времени, но они были одними из самых блестящих умов того времени или, как часто их называют, "волшебниками", и они делали что-то по какой-то причине.