cabeçalho do script de shell para melhor compatibilidade [duplicado]

Question

Qual é o melhor:

• #!/usr/bin/env sh
• #!/bin/sh
• vazio / sem cabeçalho

Eu costumava pensar que o primeiro é o melhor, de qualquer forma eu encontrei em alguns sistemas baseados em Linux (como Android) que nome do caminho está faltando, então agora eu estou pensando que a única maneira de ter shell scripts "portáteis" é não incluir nenhum cabeçalho ...

    

Answer 1

Para portabilidade, você pode seguramente assumir que #!/bin/sh encontrará um shell em sua maioria compatível com POSIX em qualquer sistema Unix ou Linux padrão, mas é realmente sobre isso.

No FreeBSD, OpenBSD e NetBSD (junto com o FreeBSD, PC-BSD e alguns outros derivados), o bash está localizado em /usr/local/bin/bash (se estiver instalado), então a abordagem /usr/bin/env fornece portabilidade entre o Linux e o BSD.

O Android não é um sistema Unix ou Linux padrão. No meu telefone Android não enraizado, nenhum dos /usr/bin/env , /bin/bash ou mesmo /bin/sh existe e o shell do sistema é /system/bin/sh .

Um script de shell que está faltando o #! (shebang) tentará executar no shell que o chamou em alguns sistemas ou pode usar um interpretador padrão diferente ( /bin/bash , por exemplo), em outros sistemas. E enquanto isso pode funcionar no Android, não é garantido que funcione em outros sistemas operacionais, onde os usuários podem optar por usar um shell interativo que não seja bash . (Eu uso o tcsh no FreeBSD, onde é o shell padrão, e o script shebang-less é interpretado pelo shell de chamada).

Então de onde estou, parece que não é possível criar um script de shell que seja portátil entre sistemas Android e não-Android (Linux ou Unix), porque o Android faz as coisas de maneira diferente.

    

Answer 2

Na minha experiência, #!/bin/sh e #!/bin/bash sempre acabaram encontrando o ambiente certo nos poucos sistemas em que trabalhei. Ainda estou para encontrar uma exceção. Eu também acho que ele está sendo usado rotineiramente em textos relacionados a script de shell que, suponho, são escritos mantendo a portabilidade em mente por causa do público diversificado.

Não é possível dizer o mesmo com #!/usr/bin/env . Alguns sistemas o instalaram como #!/bin/env e quebraram meus scripts python no passado. Então, eu vou com a segunda bala.

Aqui está um pouco de apoio para minha declaração acima:

No lançamento do CentOS 5.7, recebo o seguinte:

$ which env
/bin/env

No Ubuntu 12.04 Pangolin Preciso:

$ which env
/usr/bin/env

Além disso, pelo menos em um sistema antigo, lembro que os administradores instalaram coreutils on /opt por algum motivo (pode não ser uma prática recomendada). Como env faz parte de coreutils , os usuários acabaram recebendo /opt/coreutils/bin/env . Evidentemente, eu não usei todos os sistemas lá fora, então a resposta é baseada na minha experiência limitada.