Как настроить bash, чтобы всегда разрешать полный путь для символических ссылок

Question

Модераторы: ЭТО НЕ ДУБЛИКАТ !!!! Пожалуйста, удалите дубликат отметки.

Ответы, связанные с, на самом деле не отвечают на мой вопрос, как принятый ответ. Google только указывает на другие ответы, которые на самом деле не являются ответом на этот конкретный вопрос.

При переходе по символической ссылке на каталог оболочка bash пытается создать иллюзию, что символическая ссылка является настоящим каталогом. Однако есть много случаев, когда это ломается. Например, подумайте, что я мог бы иметь:

/usr/local/src/project-a-1.0/
/usr/local/src/project-b-2.2/

тогда у меня есть символическая ссылка в моем домашнем каталоге:

ln -s /usr/local/src/project-a-1.0 ~/project

Теперь я хочу использовать ярлык для работы с project-a:

cd ~/project

Пока все хорошо, но bash делает вид, что я на самом деле в ~/project , а не в реальном рабочем каталоге. Он даже притворяется при использовании встроенного pwd , но, конечно, не при использовании исполняемого файла /bin/pwd .

Теперь, если я хочу извлечь файл в project-b , я могу попробовать vim ../project-b<TAB> чтобы попытаться заставить завершение команды работать. Тем не менее, bash отказывается завершить это, потому что считает, что .. это каталог, содержащий домашние страницы пользователей.

Тем не менее, если я vim ../project-b-2.2/somefile.txt то это работает нормально, чего я и ожидал.

Симлинки не являются каталогами, и из-за этой ошибки в bash возникают всевозможные неудобства и даже ошибки. Я пытался найти вариант, чтобы отключить это, но все хиты Google и суперпользователя просто о том, "как я могу вручную разрешить путь ссылки" - это не то, что я хочу здесь; Я хочу, чтобы bash прекратил попытки эмулировать файловую систему поверх моей файловой системы, плохо. Конечно, существует какой-то вариант, который поставит правильность перед иллюзией?

Всплывающее окно "Подобные вопросы" указывало на два других вопроса, на которые Google уже прислал мне; оба они требуют, чтобы я передал опцию "-P" в pwd или cd или даже рекомендовал использовать readlink чтобы выяснить цель символической ссылки. Это совсем не то, что мне интересно. Я хочу, чтобы встроенный pwd и приглашение оболочки $PWD соответствовали физическому выводу системного вызова getcwd() ; эти вопросы не говорят об этом вообще.

Answer 1

Для этого есть опция всей оболочки :

-P

Если установлено, не разрешайте символические ссылки при выполнении команд, таких как cd которые изменяют текущий каталог. Вместо этого используется физический каталог. По умолчанию Bash следует логической цепочке каталогов при выполнении команд, которые изменяют текущий каталог.

Например, если /usr /sys является символической ссылкой на /usr /local /sys, то:

$ cd /usr/sys; echo $PWD
/usr/sys
$ cd ..; pwd
/usr

Если set -P , то:

$ cd /usr/sys; echo $PWD
/usr/local/sys
$ cd ..; pwd
/usr/local

Так что это должно получить вам поведение, которое вы хотите:

set -P

Answer 2

Возможно, это не то, что вы хотите услышать, но я бы сказал, что идея канонического пути к файлу ошибочна.

Во-первых, если вы создаете жесткую ссылку на существующий файл, то теперь есть буквально два разных пути к одному и тому же файлу:

$ cd "$(mktemp --directory)"
$ touch foo
$ ln foo bar
$ ls --inode 
1223418 bar  1223418 foo

Среди этих двоих нет "оригинала", и они хранят одни и те же метаданные, кроме их имени:

$ touch --date='2001-02-03 04:05:06.789' bar
$ ls -lA
total 0
[…] Feb  3  2001 bar
[…] Feb  3  2001 foo

Во-вторых, существует множество способов обращения к файлу в зависимости от контекста:

• Относительные пути к жесткой или символической ссылке
• Абсолютные пути (множественные, как показано выше) к жесткой или символической ссылке
• file:///absolute/path/to/file или другие протоколы

Все это полезно в разных контекстах.

В-третьих, Баш ничего не "притворяется" ; Там нет иллюзии, вы действительно находитесь в этом каталоге. Тот факт, что это символьная ссылка, должен быть прозрачен практически для всех действий, которые вы когда-либо совершали с ним.

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

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