Uma maneira recomendada de usar um utilitário de linha de comando que não é adicionado ao PATH

Uma solução óbvia é adicionar o diretório que contém o programa à sua PATHconfiguração . Isso é comumente praticado no Windows, mas não no Unix. Há várias razões pelas quais isso não é uma boa ideia:

• Frequentemente, o diretório que contém o executável que você quer também contém arquivos não executáveis, executáveis ​​com os quais você não se importa ou subdiretórios. Eles podem atrapalhar a conclusão. (Isso é menos problemático no Windows, onde a maioria das pessoas não usa a linha de comando, então PATHé principalmente para chamadas de programa para programa.)
• Você precisa encontrar uma maneira de controlar quais diretórios estão no PATH, e em particular remover entradas obsoletas após desinstalar um programa. (O Windows resolve isso parcialmente deixando o instalador do programa cuidar da PATHconfiguração. Mas muitos programas não vêm com um desinstalador funcional.)
• Um programa recém-instalado não será acessível a partir de shells em execução e outros programas até que você reinicie os programas de chamada. (O Windows resolve isso parcialmente tendo um “PATH do sistema” e organizando a execução da maioria dos programas por meio de um shell que obedece a esse “PATH do sistema”. Isso exclui a execução de coisas a partir de uma janela de terminal.)
• Isso não lida com coisas além de executáveis, como páginas de manual. (O Windows resolve isso parcialmente fazendo com que o instalador do programa registre suas páginas de ajuda. Mas isso pressupõe que o programa venha com um instalador.)

Criar um link simbólico em /usr/local/bin(para programas instalados em todo o sistema) ou ~/bin(para programas instalados na sua conta — você pode escolher um local diferente se quiser) (sugestão 1 na pergunta) é uma boa solução. Ele torna os programas recém-instalados imediatamente disponíveis para todos os potenciais chamadores. A instalação requer apenas a criação de um link simbólico. A desinstalação requer apenas a remoção de um link simbólico. Se você esquecer de desinstalar o link simbólico, você pode facilmente limpar: basta remover todos os links simbólicos pendurados.

Uma dificuldade com essa abordagem é que é tedioso lembrar de criar o link. Felizmente, existem ferramentas para isso: Stow ou uma de suas alternativas, como XStow . Veja Mantendo o controle de programas .

Stow e XStow também cuidam de tornar os recursos associados disponíveis, por exemplo, páginas de manual. Após desinstalar um programa, eles podem remover links simbólicos pendurados.

Existem alguns programas que não funcionam corretamente quando você os invoca por meio de um link simbólico, porque eles esperam encontrar outros arquivos no mesmo diretório (ou em um diretório próximo, por exemplo, quando você executa /path/to/bin/foo, ele procura por /path/to/lib/foolib). A maioria dos programas que fazem isso olham para o alvo do link, mas de vez em quando você encontrará um que olha para o próprio link. Com esse programa, use o método wrapper de script de shell abaixo.

Um wrapper de script de shell (sugestão 2 na pergunta) funciona, mas não é conveniente. Você tem que escrever esse wrapper para cada programa. Você tem que lembrar de removê-lo na desinstalação. Ele não cuida de recursos associados, como páginas de manual. Então é mais um método de fallback quando a abordagem de symlink não é boa o suficiente.

Uma vantagem da abordagem do wrapper de script de shell é que ele lhe dá controle sobre o caminho exato pelo qual você invoca o executável, caso o programa se importe com isso. Isso também permite que você defina variáveis ​​de ambiente, para programas que precisam de configurações especiais em seu ambiente que você não quer carregar para todo lugar. Ele também lhe dá uma oportunidade de limpar depois que o programa existir, se o programa deixar lixo por aí (por exemplo, programas que não limpam seus arquivos temporários).

Aqui está um wrapper de script de shell mínimo que cuida para fazer as coisas de forma limpa. Em particular, ele passa todos os argumentos de linha de comando corretamente. Ele também toma cuidado para não deixar o processo do wrapper de shell por aí, o que ocasionalmente importa se você estiver fazendo algum tipo de monitoramento de processo.

#!/bin/sh
exec /path/to/my/weird/executable "$@"

Um alias de shell funciona somente quando você chama o programa diretamente de um shell interativo. Ele não funciona de outros programas, ou de instâncias de shell já em execução, ou de tarefas agendadas, ou via utilitários como find -execor xargs, etc. Não consigo pensar em um bom motivo para usar esse método.

Nunca tive um Mac, mas faço isso com um aliasconstantemente. Se .zshrcfor o equivalente de Mac para .bashrc, então apenas adicione:

if [ -f ~/.zsh_aliases ]; then
    . ~/.zsh_aliases
fi

Então execute:touch ~/.zsh_aliases

Agora, basta usar qualquer editor de texto para adicionar todos os seus aliases a esse arquivo, e ele será carregado automaticamente na inicialização. Você pode rebootdigitar ou source ~/.zshrc(ou . , como acima, é o mesmo que source) para fazer isso sem reiniciar.

Alguns .zsh_aliasesexemplos diretamente do meu arquivo:

alias pdf2console='bash -c /run/media/jason/HOME/jaypc/Documents/pub/bash/myapps/pdf2console.sh
alias concatvid='/run/media/jason/HOME/jaypc/Documents/pub/bash/myapps/1_ffmpeg/concat_vid.sh'
alias mdedit='firefox /home/jason/Documents/htdocs/md2html/md-it/index.html'

Não tenho certeza se há um zshequivalente para bash -c, mas não deve ser necessário. Use-o com o caminho completo como conctvide você pode executar esse script, executável ou qualquer coisa, de qualquer diretório com argumentos e tudo. O alias mdeditabre meu editor markdown baseado em navegador no firefox. Você pode fazer muita coisa.

Eu até tenho o alias aka, para editar meu arquivo de aliases com nano, e executar sourcena saída:

alias aka='nano ~/.zsh_aliases && source ~/.zshrc'