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

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

Что является точкой '.' и точечной точкой '..' каталоги?

Взгляд на format of directories страница руководства с 1971 выпуск руководства Unix-программиста, мы видим это . и .. уже были там:

Условно, первые две записи в каждом каталоге для"." и “.. “. Первой является запись для самого каталога.

Что касается их значения, ответ может быть найден на ответе Panos. Ken Thompson объяснил как .. появился в интервью 1989 года:

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

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

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

В книге 1996 года "Внутренности UNIX: НОВЫЕ Границы" Uresh Vahalia, в Главе 8, страница 222 это указано:

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

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

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

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

2. Пользовательское удобство:

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

mv ../filename.txt .

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

3. Улучшение по MULTICS:

^{Примечание: Я никогда не работал над 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, но это - на самом деле очень плохая практика, не делайте этого.

примечание стороны: особый случай .. и . указывание на то же является inode 2 - / dir, и это имеет смысл, так как это - самая высокая точка в дереве каталогов. Конечно, .. быть ПУСТЫМ могло также работать, но это более изящно, чтобы заставить его указать на / самостоятельно.

Примечание по числу каналов и каталог Hardlinks

Как Gilles правильно указал (и сослался George Udosen), число каналов для каталога запускается с 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

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

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

Заключение

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