Que tipo de caminho no shebang é mais preferível?

Question

Nos scripts, a primeira linha deve especificar o caminho para o interpretador.
Mas em servidores diferentes Linux, Unix ou BSD, esse caminho pode ser diferente.

O que é mais preferível?

#!/usr/bin/env bash 

ou

#!/bin/bash 

    

Answer 1

Se você quiser usar a versão instalada pelo sistema de um determinado interpretador instalado em um local padrão, use o caminho direto. Se você quiser usar qualquer versão do interpretador aparece primeiro no usuário $PATH , use #!/usr/bin/env ... .

O comando env chama um comando especificado, permitindo definir ou desmarcar variáveis de ambiente:

env FOO=BAR do-something
env DISPLAY=:0.0 xterm -ls &

Se você não especificar nenhuma variável de ambiente ou outras opções, apenas invocará o comando named. (Usar dessa maneira é, sem dúvida, um truque.)

O propósito de escrever o shebang como

#!/usr/bin/env interp

é invocar o que quer que interp apareça primeiro em $PATH .

Isso significa que você não precisa saber, ao escrever o script, exatamente onde interp é (digamos, se poderia estar em /bin , /usr/bin ou /usr/local/bin ). É claro que você precisa saber que env é /usr/bin/env , mas isso parece ser razoavelmente universal.

A vantagem é que ele invoca qualquer versão do interpretador que apareça primeiro no usuário $PATH . A desvantagem é que invoca qualquer versão do intérprete aparece primeiro no usuário $PATH .

Por exemplo, suponha que eu tenha instalado uma versão pessoal de perl em meu diretório pessoal, como $HOME/bin/perl , e eu tenho $HOME/bin na frente do meu $PATH . Se eu executar um script cujo shebang é

#!/usr/bin/env perl

então ele será executado com o meu próprio executável perl instalado - o que pode não ser uma coisa boa. O autor do script provavelmente não testou com o Perl que eu construí da fonte há um mês.

Para algo como Perl ou Bash que provavelmente será instalado em um local consistente na maioria dos sistemas ( /usr/bin/perl e /bin/bash , respectivamente), usaria o caminho direto para o comando. Para algo mais obscuro que poderia ser instalado de forma diferente em sistemas diferentes, eu usaria o truque /usr/bin/env ou escreveria um instalador que ajustasse a linha shebang à medida que o script fosse instalado. (Eu costumava fazer isso para meus scripts Perl.)

UPDATE: Eu me concentrei em mais detalhes em esta resposta para esta pergunta no Unix e amp ; Site Linux .

    

Answer 2

A melhor prática é esta:

#!/usr/bin/env bash 
#!/usr/bin/env sh
#!/usr/bin/env python

E assim por diante ...

Quando o Ubuntu começou a usar o dash, alguns scripts quebraram. Houve discussão sobre isso. A maioria dos scripts foi escrita em #!/bin/sh , que era um link para / bin / bash. O consenso é o seguinte: o autor do script é responsável por especificar o interpretador. Portanto, se seu script sempre deve ser chamado com BASH, especifique-o no ambiente. Isso evita que você tenha que adivinhar o caminho, o que é diferente em vários sistemas Unix / Linux. Além disso, ele funcionará se o tomorrow / bin / sh se tornar um link para algum outro shell como / bin / wthsh ou alguma outra nonsence.

    

Answer 3

FYI é um shee-bang #! , você precisa do # . Você usa essa linha para identificar com qual interpretador executar o script.

Por padrão, o Ubuntu vincula /bin/sh ao traço

Dependendo de quanto você gostaria de saber sobre o traço e porque o traço é usado para shells do sistema ou do deamon, consulte:

cyberciti.biz dash

página de manual do Ubuntu dash

O Bash é o shell padrão usado pela maioria dos usuários do Linux e possui recursos diferentes, em seguida, traço. Um script escrito para o bash pode ou não ser executado corretamente se executado com dash, quanto mais complexo o script, menor a probabilidade de execução.

O script escrito para perl, python etc. não será executado com /bin/sh ou /bin/bash .

Então, quando você escreve um roteiro, identifica qual intérprete deve ser usado com o shee-bang

A seleção do que usar é feita pelo autor do roteiro, e um não é melhor que o outro, todos eles têm vários recursos, vantagens e desvantagens.