Por que o symlink é a solução preferida para executáveis em opt, em vez de atualizar o PATH? [fechadas]

Question

Neste answer um método para adicionar todos os subdiretórios / opt / tool / bin ao PATH é apresentado:

for d in /opt/*/bin; do PATH="$PATH:$d"; done

Mas então o Gilles afirma:

But this is rarely done. The usual method when executables in non-standard directories are to be in $PATH is to make symbolic links in a directory in the path such as /usr/local/bin. The stow utility (or xstow) can be useful in that regard.

Pelo menos uma resposta outro suporta essa afirmação.

Mas não entendo por que é preferível usar links simbólicos para executáveis em /opt/*/bin . Parece que isso adiciona manutenção extra desnecessária.

Por que um link simbólico é a solução preferida para executáveis em opt, em vez de atualizar o PATH?

    

Answer 1

Tentando responder a isso sem dizer qual solução é "melhor", mas apenas para fornecer uma explicação do motivo pelo qual Gilles poderia sugerir o uso de links simbólicos para fornecer um conjunto de ferramentas e abordar o aspecto de manutenção disso. No final, é o administrador local que decide qual a solução apropriada em seu sistema.

Ao adicionar os diretórios bin aos usuários ' PATH , adicionar uma nova ferramenta exigiria uma atualização para a variável PATH de todos os usuários (o que não estaria em vigor até que uma nova sessão do shell fosse iniciada). p>

Usando o GNU stow , como sugere Gilles, você teria uma estrutura de diretório em, por exemplo, /opt/stow com um diretório para cada ferramenta, cada um com seu próprio subdiretório bin , lib etc. Cada ferramenta normalmente teria sido instalada especificando /opt/stow/toolname como o prefixo de instalação.

Os subdiretórios seriam simbolicamente vinculados aos diretórios correspondentes em /opt by stow , portanto, o custo de manutenção é mínimo. Os únicos diretórios que você teria que adicionar ao PATH seriam /opt/bin e possivelmente /opt/sbin .

Normalmente, você teria

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

Então:

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

Isso preencheria a hierarquia /opt com os links simbólicos apropriados, permitindo que você acessasse os executáveis para ambas as ferramentas em /opt/bin . Isso presume que não há confrontos de nome nos executáveis entre as ferramentas, mas, novamente, você teria o mesmo problema ao adicionar todos esses caminhos a PATH .

Para alternar de 1,23 para 1,25 de tool-A ,

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

Nunca é necessário manter manualmente os links simbólicos ou alterar os usuários ' PATH , e a alteração seria imediata para todos os usuários.

    

Answer 2

Colocar todo o /opt/*/bin em PATH tem a desvantagem de a lista precisar ser alterada sempre que algum novo aplicativo for instalado ou outro atualizado (com uma alteração correspondente no caminho).

Os usuários precisarão fazer login novamente ou atualizar manualmente seu caminho. Para casos de uso de login-do-stuff-logout simples, isso pode não ser um problema, mas para sessões de execução longa, como qualquer pessoa executando screen ou tmux , é. (Você pode ter shells (ou Emacs) rodando com o antigo PATH e o próprio multiplexador de terminal terá o antigo PATH , o que importa se algum dia ele executar utilitários diretamente.)

Além disso, o resultado disso será uma lista visualmente desagradável de diretórios, que talvez você não queira que os usuários precisem ver. Será mais fácil para eles verificar o que o PATH deles contém se não precisarem se preocupar com os detalhes se as coisas forem instaladas em /opt .

Além disso, se você precisar definir explicitamente o PATH em algo como crontab , será mais fácil escrever apenas /bin:/usr/bin/:/opt/bin ou algo assim, em vez de precisar gravar e atualizar a lista de diretórios reais em %código%. Você não pode usar um loop e um glob em /opt .

Quanto à sobrecarga administrativa, Kusalananda discutiu crontab , mas mesmo sem ela, criando os links simbólicos necessários pode ser feito apenas executando stow em ln -s ../someutil-1.2.3/bin/* . . (Remover os antigos não é que trivial, mas depois deixar links quebrados para trás quando você remove o diretório do utilitário não afeta o comportamento do shell, é apenas um pouco sujo.)

    

Answer 3

O principal problema que precisa ser resolvido é o conflito de nomes de programas.

Ter um PATH grande não é mais um problema, pois há um hash para locais de caminho binário no Bourne Shell desde, por exemplo, 1977.

É incomum ter links simbólicos, exceto por um motivo:

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

Se você, por exemplo, defina seu PATH para:

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

você encontra todas as ferramentas GNU antes das ferramentas padrão do sistema.

Isso pode permitir que você use as ferramentas GNU facilmente, mas isso também resulta em ser forçado a, por exemplo. use o GNU chmod que perde o suporte para ACLs e use o GNU tar que é conhecido por criar arquivos com problemas de portabilidade.

Vamos supor que você esteja basicamente interessado no GNU xgettext , mas caso contrário, use as ferramentas oficiais do sistema que incluem suporte para recursos estendidos do sistema, as quais as ferramentas GNU não estão cientes. Isso pode ser feito criando um próprio diretório bin, por exemplo, chamando:

mkdir ~/bin

Se você criar um link simbólico:

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

e configure este PATH:

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

você receberá o GNget xgettext se você chamar xgettext , mas as ferramentas oficiais do sistema se você ligar, e. chmod ou tar . Como é comum ter links simbólicos para as ferramentas GNU, mas com seu prefixo nativo em /usr/bin/ (por exemplo, /usr/bin/gtar to /usr/gnu/bin/tar ) você ainda pode intencionalmente usar o GNU tar chamando gtar .

BTW: /opt/bin não faz parte do padrão UNIX FHS e este padrão lista

/opt/<vendor>/bin

e não

/opt/<project>/bin

mesmo que haja exemplos para o último.