Ao configurá-lo para que eu pudesse executar o Sublime Text do bash, descobri dois métodos de fazer isso através de diferentes tutoriais:
Método 1) Crie um symlink de /usr/local/bin/subl para o bin dir do Sublime:
sudo ln -s /Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl /usr/local/bin/subl
Isso levou vantagem que /usr/local/bin já está na minha variável PATH.
... ou ...
Método 2) Atualize seu PATH para incluir o caminho para a pasta bin do Sublime:
export PATH="/Applications/Sublime Text.app/Contents/SharedSupport/bin/":$PATH
Ambos funcionam, mas eu estou querendo saber se um método é melhor que o outro, ou eles são igualmente bons?
A única vantagem que eu posso potencialmente ver é para o Método 1 se é vantajoso ter menos diretórios no seu diretório PATH (velocidade / desempenho na procura pelo executável?).
Se você está procurando o caminho para executar / executar o programa / script como um comando diretamente do terminal , então eu acho que colocar scripts ou links para /usr/local/bin é uma boa escolha!
Além disso, a vantagem é que já está no caminho. Visite esta postagem relacionada .
Mas se um diretório de programa fornecer vários executáveis, então acho que exportar o caminho desse diretório pode ser útil / melhor que criar vários links simbólicos individualmente.
Adicionar um link simbólico a um diretório que já está no seu PATH é geralmente preferível.
Se você deseja que o software fique visível em todo o sistema (por outros usuários), adicione um link simbólico a /usr/local/bin . Se você quiser que o software fique visível apenas para você, adicione uma vez $HOME/bin/ ao seu PATH (algumas distribuições estão configurando o bash shell para adicionar esse diretório automagicamente se ele existir) e adicione links simbólicos dele.
Você deve evitar ter um PATH muito longo (evite adicionar um diretório para cada aplicativo recém-instalado), tanto para desempenho (mas alguns shells estão armazenando em cache PATH lookup, então isso pode não importar muito) e para fins de manutenção (você terá uma confusão se o seu PATH contiver dezenas de diretórios); isso também é verdade para LD_LIBRARY_PATH (então é melhor adicionar links simbólicos de $HOME/lib/ ...).
Você também pode considerar o uso do armazenamento GNU que automatiza parcialmente o processo (tentei para usá-lo há alguns anos atrás, mas senti que não vale a pena o fardo).
Por fim, muitos softwares que você compila a partir do código-fonte podem ser configurados para serem instalados em algum lugar diferente do diretório /usr/local/ e seu /usr/local/bin/ . Para software livre configurado com as facilidades GNU autoconf (ou seja, com um script configure gerado a partir de configure.ac . ...), você pode querer passar --prefix=$HOME/pub/ --exec-prefix=$HOME/bin/ e algumas outras opções (por exemplo, --program-suffix=-mine , ...) em tempo de compilação.
Um terceiro método de fazer seria encapsular seu executável em algum script de shell que export -s um% aumentadoPATH por exemplo usando export PATH=$PATH:/opt/something/bin .... (isso é necessário se o executável estiver bifurcando mais processos internos executados através de execvp ); BTW a maioria das instalações do firefox estão fazendo isso (assim firefox ou mozilla seria um script de shell terminando com exec mozilla.bin ....), ou em um script que termina em exec -o caminho completo. então você pode simplesmente adicionar um pequeno script de shell como $HOME/bin/sublimetext (assumindo que $HOME/bin/ é já no seu PATH ) contendo
#!/bin/sh
# file $HOME/bin/sublimetext
# if needed add export PATH=$PATH:/Applications/Sublime\ Text.app/Contents/SharedSupport/bin
exec /Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl "$@"
e você pode até nomear esse script $HOME/bin/subl se quiser; não esqueça de tornar seu script executável com chmod u+rx $HOME/bin/subl