Должен ли я включить косую черту / в символическую ссылку на каталог?


30

Символьная ссылка на каталог дает разные результаты в ls -lзависимости от того, я ln -s dirили ln -s dir/. Но в чем же разница, и какую мне лучше выбрать?

Ответы:


9

Там нет разницы. (Будет разница, если целью не будет существующий каталог.)

Последняя косая черта могла закончиться из-за завершения оболочки: с некоторой конфигурацией ln -s tarTabSpacelinkзавершается до ln -s target/ link.


Похоже, что связанный вопрос касается множественных последовательных слешей в путях, но не о конечных слешах в ссылках. Я не уверен, что здесь есть что сказать.
mwfearnley

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

@mwfearnley Это логическое следствие: если foo -> bar/тогда foo/quxэквивалентно bar//qux. Хотя название вопроса, формально говоря, не включает foo -> bar/, я также обсуждаю этот случай в своем ответе там.
Жиль "ТАК - перестать быть злым"

Привет, спасибо за ответ. Он говорит мне, что пути, включая символические ссылки, эквивалентны. Это не обязательно говорит мне, что происходит, если я получаю доступ к самой символической ссылке (без завершающего слеша), и, не будучи экспертом по Unix, я не обязательно знаю, что означает или не означает «эквивалентность».
mwfearnley

Существует по крайней мере один крайний случай, когда это имеет значение, поэтому мне пришлось понизить этот ответ.
Flimm

27

Единственное, о чем я могу думать, это то, что он «защищает» вас от того, кто удаляет каталог и создает файл.

[user@host linktest]$ mkdir test
[user@host linktest]$ ln -s test/ slash
[user@host linktest]$ ln -s test noslash
[user@host linktest]$ ls -l
total 4
lrwxrwxrwx 1 paul paul    4 Feb 21 21:00 noslash -> test
lrwxrwxrwx 1 paul paul    5 Feb 21 21:00 slash -> test/
drwxrwxr-x 2 paul paul 4096 Feb 21 20:59 test
[user@host linktest]$ file *slash
noslash: symbolic link to `test'
slash: symbolic link to `test/'
[user@host linktest]$ rmdir test
[user@host linktest]$ file *slash
noslash: broken symbolic link to `test'
slash: broken symbolic link to `test/'
[user@host linktest]$ touch test
[user@host linktest]$ file *slash
noslash: symbolic link to `test'
slash: broken symbolic link to `test/'
[user@host linktest]$

Версия с косой чертой прерывается, когда цель заменяется файлом.


3

Интересный вопрос. Я сделал небольшой тест:

$ mkdir dir
$ ln -s dir/ test_slash
$ ln -s dir test_noslash
$ ls -l
total 4
drwxr-xr-x 2 vrusinov vrusinov 4096 Feb 21 16:41 dir
lrwxrwxrwx 1 vrusinov vrusinov    3 Feb 21 16:41 test_noslash -> dir
lrwxrwxrwx 1 vrusinov vrusinov    4 Feb 21 16:41 test_slash -> dir/
$ strace ls test_slash 2> trace_slash
$ strace ls test_noslash 2> trace_noslash
$ wc -l trace_*
   79 trace_noslash
   79 trace_slash
$ diff -u trace_* | less

Как видите, нет разницы в количестве системных вызовов (по крайней мере, для ls), и трассировки выглядят очень похоже. Тем не менее, это всего лишь тест дампа, и я не уверен - могут быть некоторые различия.


Мне также интересно, если это действительно имеет значение, но зачем тогда хранить этот дополнительный слеш?
Тобиас Кинцлер

2

Ваш вопрос действительно о поведении lsпрограммы.

1) Если вы делаете, ls -l $dirгде $ dir на самом деле является символической ссылкой, вы получаете информацию о символической ссылке.

2) Если вы делаете, ls -lL $dirгде $ dir является символической ссылкой на каталог, вы получаете информацию о целевом каталоге.

3) Если вы сделаете ls -l $dir/.это, вы должны будете перейти по символической ссылке и предоставить информацию о целевом каталоге.

4) В противном случае ls -l $dir/результаты могут совпадать с № 1 или № 3 в зависимости от используемой версии ls. Я привык к более старой версии Solaris, делающей это как # 1, и был удивлен, что Linux сделал это как # 3.

и какой я должен предпочесть почему?

Без косой черты, если вас может беспокоить, является ли заданное имя каталога действительным каталогом, а не символической ссылкой на каталог.

С косой чертой, если вас больше волнуют файлы в каталоге, а не сам каталог.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.