Последствия наличия переменной переменной $ PATH?

Функция, которая мне действительно нужна, – это создать «виртуальные каталоги», объединив коллекцию реальных каталогов (так что ваш /usr/bin фактически является виртуальной вещью, указывающей на массив каталогов).

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

На данный момент я использую переменную $ PATH в качестве обходного пути, сохраняя в ней всю коллекцию каталогов, которые я хочу «объединить» (и планирую использовать другие, такие как $ MANPATH, для страниц руководства, а также аналогичные эквиваленты для библиотек).

На данный момент я не сталкиваюсь с какой-либо проблемой производительности, поскольку коллекция «объединенных каталогов» невелика, но мне интересно, могу ли я испытывать проблемы в случае, если число придет в будущем в сотни каталогов (я не знаю, но знаю, будет ли такое большое число, хотя).

Ожидаемое количество «объединенных» каталогов, которые я предполагаю в обозримом будущем, составляет от 40 до 50 .

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

Как вы думаете, я могу продолжить подход $ PATH, или я должен остановиться, пересмотреть и изучить другие варианты?

2 Solutions collect form web for “Последствия наличия переменной переменной $ PATH?”

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

Я бы не ожидал, что наличие длинной $PATH вызовет серьезные проблемы с производительностью при использовании разумной оболочки.

Для альтернативного решения взгляните на GNU Stow .

Решение $PATH сильно зависит от успешной установки $PATH при загрузке, что приводит к сбою всей установки, если конфигурация окружения повреждена или удалена каким-то образом.

Метод symlink более надежный, поскольку он в большей степени зависит от самостоятельности, хотя немного сложнее настроить.

Проект GNU Stow и nixOS – это два способа использования метода symlink , который вы можете использовать или изучить для понимания того, как он работает на практике.

  • * в конце пути к каталогу
  • Доступ к исполняемым файлам PgSQL из любого места
  • Разрешение местоположения / регистрации исполняемого файла в системе?
  • открыть файл, используя CDPATH и символическую ссылку
  • Interesting Posts

    Как определить пики в аудиофайле?

    vsftpd – как разрешить пользователю удалять файлы, добавленные другим пользователем / группой

    время доступа к файлу после загрузки файла в кеш

    Прерывает ли sed поврежденный целевой файл?

    iptables и обеспечение smtp

    Один ключ на клавиатуре производит дополнительные нажатия клавиш для каждой нажатой клавиши

    Преобразование матрицы с размером (nxn) в матрицу с комбинацией столбца строки *

    Системный раздел EFI необходим?

    Настроить экран GNU для повторного подключения к текущей ширине терминала при повторном подключении?

    Почему люди все еще используют SFTP-тюрьмы на основе chroot SSH, а не пространства имен Systemd?

    Vim: скопируйте, затем вставьте несколько раз

    Спящий режим двойной загрузочной машины с разделяемым разделом для записи

    Объединить входные данные из нескольких файлов / труб без сбивающих линий или блокировки?

    kde5 breeze-dark theme и значки kde не работают в i3wm

    Используя инструмент gpg-agent-connect, восстановите файл закрытого ключа ssh

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