Почему 'ls -L' печатает имя самой ссылки, а не имя файла, на который указывает ссылка?
Я не знаю ни одного чистого способа.
Вы можете отключить специальную обработку пробелов, которую less использует для отображения подчеркивания/жирного, а затем использовать экранированные пробелы для поиска нужной вам строки:
- Откройте less (например.
man less) - Выключите UNDERLINE-SPECIAL (введите
-U) - Введите строку поиска, используя
Например, для подчеркнутого текста можно набрать
/_<C-v><C-h>l_<C-v><C-h>e_<C-v><C-h>s_<C-v><C-h>s<Enter>
...для поиска подчеркнутого слова "меньше".
Для полужирного текста можно набрать
/l<C-v><C-h>le<C-v><C-h>es<C-v><C-h>ss<C-v><C-h>s<Enter>
... для поиска полужирного слова "меньше".
Как я уже сказал, нет чистого способа.
EDIT: Как отмечает Стефан в комментариях, вы можете использовать точку (которая соответствует любому символу) вместо литерала
/l.le.es.ss.s
для поиска полужирного и
/_.l_.e_.s_.s
для поиска подчеркнутого.
По-прежнему необходимо сначала отключить UNDERLINE-SPECIAL, что делает подчеркнутый/жирный текст не очень читабельным.
При использовании параметров -L или -H для символических ссылок, чтобы отображалось имя ссылки, а не имя файла, связанного с файлом, является согласованность.
Заметное различие между символическими ссылками и жесткими ссылками заключается в том, что при перечислении с помощью ls -l разрешения символических ссылок мало используются (за пределами начальных s ) и имя файла показывает как имя ссылки, так и путь, связанный с именем, используя соглашение символическая ссылка -> цель . Обоснование такого поведения заключается в том, что команда ls -l работает независимо от того, существует цель или нет. Его роль заключается в предоставлении информации о самой символической ссылке.
Параметр -L был добавлен, чтобы разрешить поведение, подобное тому, что происходит с жесткой ссылкой. Права доступа к файлам являются фактическими, то есть разрешениями базового inode, и запрашивается имя файла, а не что-то еще. Это может сбить с толку, если вы запустите, например, ls -lL a * , и имена файлов, не начинающиеся с a , будут отображаться. Более того, если целевая ссылка не существует, нет разрешений для отображения, потому что нет базового inode, и команда ls -lL завершается ошибкой.
Еще одна веская причина, объясняющая, почему это делается таким образом, заключается в том, что символическая ссылка часто связана с относительным или абсолютным путем, а не с одним именем файла, но нет возможности отображать относительный или полный путь с помощью ls -l , только простые имена файлов без косой черты или точки…
Потому что имя файла на другом конце ссылки не является (или может не являться) именем файла в каталоге, к которому вы обращаетесь с помощью ls.
Две проблемы с отображением имени цели символической ссылки вместо имени самой ссылки:
Файл не существует. Если имя цели символической ссылки отображается в списке каталогов, можно подумать, что это имя файла в этом каталоге, но это не так. Имя цели не является именем, по которому вы обращаетесь к файлу в этом каталоге; файл с таким именем не существует (в этом каталоге), или, в худшем случае, это может быть совершенно другой файл (или каталог, или что-либо еще), когда к нему обращаются по этому имени.
Может показаться, что файлы имеют одинаковые имена. Если отобразить имя цели символической ссылки, то можно обнаружить, что оно полностью совпадает с именем другого файла в этом каталоге, что не может быть правдой в системе Unix.
В таких случаях это приводит к путанице для пользователей, и им придется проверять листинг с помощью ls без -L, что сделает опцию -L довольно бессмысленной.
Это (не отображение имени цели) также является поведением, указанным в POSIX, вполне явно:
Оценивайте информацию о файле и тип файла для всех символических ссылок (названных в командной строке или встречающихся в иерархии файлов) как информацию о файле, на который ссылается ссылка, а не саму ссылку; однако,
lsдолжен записывать имя самой ссылки, а не файла, на который ссылается ссылка. Когда-Lиспользуется с-l, записывайте содержимое символических ссылок в длинном формате (см. раздел STDOUT).
В разделе "Обоснование" руководства POSIX ls об этом больше ничего не говорится.