Digamos que eu tenha alguns diretórios:
/Users/user1/ApplicationThing/
/Users/user1/Documents/
/Users/user1/other/directory/it/doesnt/matter/
Digamos que haja um arquivo main.shem .../ApplicationThing/, que também depende de outro arquivo dependancy.sh.
Quero poder estar em qualquer outro diretório e executar o main.shWD como meu CWD, como se o .../ApplicationThing/diretório de conteúdo estivesse em todos os outros diretórios do sistema. Não como em with $PATH, mas como se o conteúdo estivesse realmente dentro do diretório, mas não deveria aparecer em preenchimentos automáticos ou mesmo em ls -l.
Responder1
Parece que ApplicationThing deve ser corrigido para encontrar suas dependências em um local específico, mesmo quando chamado com um diretório de trabalho diferente.
Você poderia fazer isso definindo uma variável de ambiente:
export ApplicationThingHome=/Users/user1/ApplicantionThing
e referindo-se a todas as dependências do main.shuso do valor dessa variável (com opcionalmente um bom padrão se a variável não estiver definida), por exemplo
${ApplicationThingHome:-/usr/local/ApplicationThingDefaultDir}/dependancy.sh
em vez de
./dependancy.sh
Então você poderia colocar main.sho diretório $PATHe usá-lo em qualquer diretório.
Sua solução proposta teria um problema: se você estiver em qualquer outro diretório e desejar criar um arquivo chamado, digamos, main.shou dependency.shlá, você acabará sobrescrevendo os respectivos arquivos do ApplicationThing. Você seria literalmente incapaz de ter/usar qualquer outro main.shque não fosse aquele que pertence ao ApplicationThing... e os diretórios foram inventados justamente para evitar problemas como esse!
Claro, você poderia estabelecer como condição que os "pseudo-arquivos" estivessem lá apenas quando main.shfossem executados primeiro ... mas então você precisaria de outro conjunto de ferramentas para ver o que main.shvê, a fim de solucionar o problema sempre que isso não acontecer O que você esperava.
Se você não conseguir consertar o ApplicationThing, poderá criar um script wrapper para chamar o ApplicationThing de qualquer lugar do sistema e colocarquescript em um diretório incluído em seu $PATH:
#!/bin/sh
# set the correct working directory for silly ApplicationThing
cd /Users/user1/ApplicationThing
# if ApplicationThing has any other environment requirements,
# this would be a great place to ensure they're satisfied too.
# Now execute the main.sh of ApplicationThing, giving it any
# command line arguments that were given to this script, exactly as-is.
exec ./main.sh "$@"
Como esse script será executado como um processo separado, o cdcomando no script não afetará de forma alguma a sessão que chama o script. A execpalavra-chave na execução main.shevita deixar um processo extra entre o shell de chamada e o main.sh.
Com essa abordagem, se main.shusar nomes de arquivos como parâmetros, você terá que fornecê-los como nomes de caminhos absolutos, pois quaisquer nomes de caminhos relativos seriam interpretados como main.shrelativos ao diretório do ApplicationThing, e não como relativos ao CWD da sessão de chamada.
Se isso for um problema, você pode escrever um pré-processamento mais elaborado para os parâmetros da linha de comando antes de passá-los para main.sh.Esta pergunta do StackExchangetem algumas idéias que você pode achar aplicáveis.