Onde devo armazenar aplicativos de linha de comando?

46

Quando eu baixa aplicativos de linha de comando, eles estão localizados no meu ~/Downloads/diretório. Mas acho que este é o lugar errado para ter um aplicativo de linha de comando localizado. Onde no sistema de arquivos do Mac OS X devo armazenar aplicativos de linha de comando?

/Applications/também parece errado, é mais para aplicativos de desktop. E /bin/soa mais para aplicativos que pertencem ao OS X.

applications command-line filesystem Jonas
fonte
Concordo com o seu sentimento de que colocar as coisas diretamente em / bin ou / Applications é geralmente uma forma ruim. A resposta de Patrix é o local mais canônico que eu já vi para o armazenamento geral de programas e scripts em linha de comando.
bmike
Duplicar: apple.stackexchange.com/q/80902/20459
rm -rf
2
Não os vejo como duplicados, pois a pergunta vinculada parece mais sobre malabarismo com várias opções de terceiros e isso é mais puro - para onde vão meus aplicativos baixados manualmente.
bmike

Respostas:

44

Como o OS X vem de uma herança unix, convém armazenar arquivos do sistema /usr/local/binpara aplicativos de linha de comando e scripts que pertencem ao sistema localmente e não a um usuário específico. Pode ser necessário criar este diretório primeiro executando:

sudo mkdir -p /usr/local/bin

Você pode mover qualquer aplicativo de linha de comando para essa pasta executando:

sudo mv my-binary /usr/local/bin/

Para garantir que faça /usr/local/binparte do seu caminho de pesquisa padrão no Terminal, verifique o conteúdo /etc/pathse adicione-o, se necessário:

grep -w /usr/local/bin /etc/paths || sudo sh -c 'echo /usr/local/bin >> /etc/paths'

Alguns usuários criam um segundo diretório para scripts no nível do usuário, mas isso está ainda mais sujeito a preferências pessoais.

Normalmente, faço um diretório bin em cada pasta do usuário e oculto-o no Finder - mas você pode tomar essa decisão se deseja ocultá-lo:

 mkdir ~/bin
 chflags hidden ~/bin

Nesse caso, convém que o caminho de cada usuário inclua esse local modificando os scripts de inicialização do shell ( ~/.bash_profilepara o bash, que é o shell padrão)

 export PATH=$PATH:~/bin

ou codificando o caminho para cada aplicativo quando você o executa.

nohillside
fonte
3
Esta é absolutamente a melhor sugestão, e a que eu daria a quem perguntasse. Vou adicionar apenas duas coisas: 1) /etc/launchd.conf também pode ser um local onde o caminho precisa ser adicionado, 2) embora eu use / usr / local / para utilitários Unix instalados via homebrewpara meus próprios scripts de shell I tenho um ~ / Dropbox / bin / que também adicionei ao meu $ PATH para que eu tenha todos os meus scripts de shell personalizados em todos os meus Macs. Mas eu faço isso além de / usr / local / bin / e não em vez disso.
TJ Luoma
/ usr / local / bin é o local tradicional do UNIX para os scripts de um usuário, que dá acesso a qualquer outro usuário no sistema. A colocação de scripts ali colocará os scripts no $ PATH de todos os usuários sem esforço. Mas acredito que a maneira do Mac , já que a maioria dos Macs tem um único usuário, é criar um ~/bindiretório, torná-lo invisível chflags uchg ~/bine adicioná-lo aos usuários ~/.bash_profilepara torná-lo parte dos usuários $ PATH. ~/biné um local superior para segurança e migração. Caso contrário, você deve se lembrar das coisas que você deixou em / usr / local / bin. E ln -s ~/bin ~/Dropbox/também é legal.
Chillin
7

Considere criar um /optdiretório, que é outro local em que o software Unix personalizado apareceria por convenção.

Matt Stephenson
fonte
5
/opt/é muito útil para aplicativos completos, ao passo que /usr/local/bin/é mais apropriado para scripts de linha de comando independentes. Geralmente é preferível usar /opt/nos casos em que uma coleção de scripts relacionados atua como uma biblioteca (por exemplo, /opt/myscriptslib/bin/).
plasmid87
Thanx por seus conselhos. Eu criei pessoalmente a pasta / opt / para colocar meu software e, em seguida, criei links simbólicos para / usr / local / bin para todos os executáveis ​​... então não há necessidade de adicionar a variável de ambiente / opt / myspecific-soft no caminho .
рüффп