Существует ли подходящий термин для физического пути, доступного через символическую ссылку?

Я потратил последний час на размышления о том, как назвать свойство, которое означает полную противоположность «разрешенной, физической реальной траектории» .

Например, предположим, что /foo/bar/ является обычным физическим путем. Если в /quux была создана символическая ссылка, которая просто указывала на /foo , целесообразно ли ссылаться на все доступные через /quux/foo/bar/ как «символический путь» …?

Это в основном вопрос о номенклатуре, потому что я не уверен, есть ли более точный способ ссылаться на неразрешенный путь. Я бы использовал «рабочий путь», но этот термин звучит слишком специфично для процесса.

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

  • Как я могу настроить переименование подкастов после их загрузки с помощью gPodder?
  • Необходимость grep-файла с конкретным письмом и переход в другую папку Linux
  • Открыть несколько файлов в папках с определенным шаблоном имени
  • Поиск совпадающих файлов с подстановочными знаками без использования find в сценарии bash
  • Как вы называете «счастливую собаку» частью файла «happy-dog.png»?
  • Как изменить использование детоксикации по умолчанию, поэтому он просто не заменяет пробелы символами подчеркивания
  • в чем смысл «-» в имени файла?
  • Как удалить файл с именем «>»?
  • 2 Solutions collect form web for “Существует ли подходящий термин для физического пути, доступного через символическую ссылку?”

    Если вы хотите быть действительно педантичным, вы можете сказать, что на самом деле нет такой вещи, как «физический путь». Unix имеет

    • Абсолютное имя пути: путь, начинающийся с одного или более двух символов <slash> .

    • Относительное имя пути: путь не начинается с символа <slash> .

    Если имя пути содержит символическую ссылку, это все равно «путь». Других условий для этого в стандарте POSIX нет.

    Однако утилита pwd имеет два флага: -P и -L , но без указания относительно того, что эти буквы сокращают:

    -L

    Если переменная среды PWD содержит абсолютный путь к текущему каталогу и имя пути не содержит каких-либо компонентов, которые являются точками или точками, pwd должен записать это имя пути в стандартный вывод, за исключением того, что если переменная среды PWD длиннее, чем {PATH_MAX} байты, включая завершающий нуль, не указано, записывает ли этот путь в стандартный вывод или ведет себя так, как если бы была указана опция -P . В противном случае параметр -L должен вести себя как опция -P .

    -P

    Путь, записанный на стандартный вывод, не должен содержать компонентов, относящихся к файлам символической ссылки типа. Если есть несколько путей, которые утилита pwd могла бы записать на стандартный вывод, один из которых начинается с одного символа <slash> и одного или нескольких, начинающихся с двух символов <slash> , тогда он должен написать путь, начинающийся с одного символа <slash> , Имя пути не должно содержать лишних символов <slash> после одного или двух символов <slash> .

    Конечно, можно сделать вывод о логическом и физическом значении этих двух флагов, а версия GNU coreutils этой утилиты даже имеет эти два слова как длинные варианты.

    Таким образом, ответ «логический путь».

    Ну, пара из них более коллоквиальна, чем определенная, но:

    Если ссылка всегда будет указывать на файл независимо от того, должен ли использоваться исходный файл или ссылка, следует использовать псевдоним (обратите внимание, что псевдоним может использоваться для чтения файлов и каталогов, но не для записи в оригинал).

    Если ссылку можно переместить, но файл не может, и данные могут быть прочитаны из связанного файла / каталога по ссылке, но не записаны, тогда следует использовать Soft Link , Symlink или Shortcut .

    Если обе ссылки и цель могут быть перемещены, и данные могут быть прочитаны и записаны в файл / каталог по ссылке, тогда следует использовать Hard Link .

    Например, Symlink/Soft Link будет считаться системой как /foo/bar/ при доступе к ссылке. Alias /quux/foo/bar/ бы доступ к нему как /quux/foo/bar/ при чтении, но /foo/bar/ при записи, а Hard Link /quux/foo/bar/ бы доступ к нему как /quux/foo/bar/ при записи, а также при чтении.

    Interesting Posts

    Исключить один исполняемый файл из PATH, без chmod -x it

    Каков следующий шаг в устранении неполадок с этим отказом беспроводного соединения?

    Настройка нескольких видеопотоков с точками публикации для клиентов

    Сценарий Telnet BASH – вывод не сохраняется

    Какое минимальное использование диска урезанной установки Debian 7 на VPS?

    Каковы преимущества использования OmniOS, чем SmartOS или OpenIndiana?

    Запустить mplayer с помощью x11 из текстовой консоли?

    Solaris SMF vs Linux Upstart

    Как присвоить значение переменной внутри цикла for в bash?

    Копирование большого дерева с одной машины на другую, сохранение права собственности

    Отслеживание выполнения команд после sudo другому пользователю

    Повтор клавиатуры без нажатия клавиши

    Синхронизировать каталог с другим каталогом

    Вывод из strace в другое окно

    awk: Извлечение фиксированного числа строк, в котором последнее число строк может изменяться

    Linux и Unix - лучшая ОС в мире.