Почему символическая ссылка является предпочтительным решением для исполняемых файлов в opt вместо обновления PATH? [closed]

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

При добавлении каталогов binв пользовательские PATHдобавление нового инструмента потребует обновления всех пользовательских PATHпеременных (, которые не будут действовать до тех пор, пока не будет запущен новый сеанс оболочки ). ].

Используя GNU stow, как предполагает Жиль, у вас будет структура каталогов, например,. /opt/stowс одним каталогом для каждого инструмента, каждый со своим собственным подкаталогом bin, libи т. д. Каждое средство обычно устанавливалось с указанием /opt/stow/toolnameв качестве префикса установки.

Подкаталоги будут символически связаны с соответствующими каталогами в /optпосредством stow, поэтому стоимость обслуживания будет минимальной. Единственными каталогами, которые вам нужно будет добавить в PATH, будут /opt/binи, возможно, /opt/sbin.

Как правило, у вас будет

/opt/stow/tool-A-1.23
/opt/stow/tool-A-1.25
/opt/stow/tool-B-3.0

Тогда:

cd /opt/stow
stow tool-A-1.23
stow tool-B-3.0

Это заполнит иерархию /optсоответствующими символическими ссылками, что позволит вам получить доступ к исполняемым файлам для обоих инструментов в /opt/bin. Это предполагает, что в исполняемых файлах между инструментами нет конфликтов имен, но опять же, у вас будет та же проблема при добавлении всех этих путей в PATH.

Для переключения с 1,23 на 1,25 из tool-A,

cd /opt/stow
stow -D tool-A-1.23
stow tool-A-1.25

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

Основная проблема, которую необходимо решить, — конфликты имен программ.

Наличие большого PATHбольше не проблема, так как в оболочке Bourne есть хеш для расположения двоичных путей, т.е. 1977.

Необычно иметь символические ссылки, за исключением одной причины:

To be able to have an own selection of programs that differs from the cluster view.

Если вы, например. установите PATH на:

PATH=/usr/gnu/bin:/usr/bin

вы найдете все инструменты GNU перед стандартными системными инструментами.

Это может позволить вам легко использовать инструменты GNU, но это также приводит к необходимости, например,. использовать GNU chmod, в котором отсутствует поддержка ACL, и использовать GNU tar, который известен тем, что создает архивы с проблемами переносимости.

Предположим, что вы в основном заинтересованы в GNU xgettext, но в остальном предпочитаете использовать официальные системные инструменты, которые включают поддержку расширенных системных функций, о которых инструменты GNU не знают. Это можно сделать, создав собственный каталог bin, например. вызов:

mkdir ~/bin

Если вы затем создадите символическую ссылку:

cd ~/bin
ln -s /usr/gnu/bin/xgettext

и установите этот ПУТЬ:

PATH=~/bin:/usr/bin:/usr/gnu/bin

вы получите GNU xgettext, если вы позвоните xgettext, но официальные системные инструменты, если вы позвоните, например. chmodили tar. Поскольку обычно есть символические ссылки на инструменты GNU, но с их собственным префиксом в /usr/bin/(, например. с /usr/bin/gtarпо/usr/gnu/bin/tar)вы по-прежнему можете намеренно использовать GNU tar, вызвав gtar.

Кстати,:/opt/binне является частью стандарта UNIX FHS, и в этом стандарте перечислены

/opt/<vendor>/bin

, а не

/opt/<project>/bin

хотя есть примеры и последнего.