Como fonte '. nome do arquivo 'confiável?

Question

A especificação POSIX atual não especifica nenhuma opção para o ponto . builtin.

Se eu fizer algo como:

$ echo 'echo .' > /tmp/-foo
$ PATH=/tmp "$shell" -c '. -foo'

então o resultado é variado entre os shells:

• dash , ash , ksh88 , shell Bourne, schily sh, schily osh, heirloom sh funcionam bem.
• bash , yash , ksh93 , pdksh , mksh , posh não. Alterar o comando para . -- -foo funciona nesses shells.

E também, usar -- é uma maneira não-compatível, porque especificação POSIX diz que incorporado que não esteja em conformidade com as Diretrizes de Sintaxe do Utilitário ignorará -- .

zsh é o único shell que funciona nos dois casos.

Então, como posso fazer com que . filename funcione de maneira confiável em shells compatíveis com Bourne ou POSIX?

    

Answer 1

Para evitar efeitos dependentes do shell, passe um caminho completo para . . . /absolute/path/to/script e . relative/path/to/script funcionam em todos os shells.

A pesquisa de caminhos raramente é útil para scripts de origem. Se você quiser a pesquisa PATH, poderá fazer a pesquisa manualmente caso o nome do arquivo comece com - . Ou você pode exigir que o nome do arquivo não comece com - , para manter as coisas simples.

    

Answer 2

Suponho que isso seja em parte uma questão teórica.

Em termos práticos, eu faria isso funcionar de forma confiável, evitando - como o primeiro caractere do script incluído ou fornecendo um caminho de script (relativo ou absoluto, não importa).

Novamente, de uma perspectiva prática, eu prefiro codificar um shell conhecido, mas se isso não fosse possível, eu provavelmente acabaria com uma feia declaração case envolvida dentro de uma função. A menos que a generalização tenha que se estender para *csh shells também, nesse caso eu provavelmente fugiria.