Por que #! / Usr / bin / env bash é superior a #! / Bin / bash?

Já vi em vários lugares, incluindo recomendações neste site ( qual é o Bash shebang preferido? ), Para usar #!/usr/bin/env bashpreferencialmente #!/bin/bash. Eu já vi um indivíduo empreendedor sugerir usando#!/bin/bash estava errado e a funcionalidade do bash seria perdida ao fazer isso.

Tudo isso dito, eu uso o bash em um ambiente de teste rigidamente controlado, onde cada unidade em circulação é essencialmente um clone de uma única unidade mestre. Entendo o argumento da portabilidade, embora não seja necessariamente aplicável no meu caso. Existe algum outro motivo para preferir #!/usr/bin/env bashas alternativas e, assumindo que a portabilidade era uma preocupação, existe algum motivo para usá-lo que poderia quebrar a funcionalidade?

#!/usr/bin/envpesquisas PATHpara bash, e bashnem sempre está em /bin, particularmente em sistemas não-Linux. Por exemplo, no meu sistema OpenBSD, ele está /usr/local/bininstalado, pois foi instalado como um pacote opcional.

Se você tem absoluta certeza de que bashestá dentro /bine sempre estará, não há mal em colocá-lo diretamente em sua mente - mas eu recomendaria isso porque todos os scripts e programas têm uma vida além do que inicialmente acreditamos que eles terão.

A localização padrão do bash é /bine suspeito que isso seja verdade em todos os sistemas. No entanto, e se você não gostar dessa versão do bash? Por exemplo, eu quero usar o bash 4.2, mas o bash no meu Mac está em 3.2.5.

Eu poderia tentar reinstalar o bash, /binmas isso pode ser uma má ideia. Se eu atualizar meu sistema operacional, ele será substituído.

No entanto, eu poderia instalar o bash in /usr/local/bin/bashe configurar meu PATH para:

PATH="/usr/local/bin:/bin:/usr/bin:$HOME/bin"

Agora, se eu especificar bash, não entendo o antigo e bruto /bin/bash, mas o mais novo e mais brilhante /usr/local/bin. Agradável!

Exceto que meus scripts de shell têm essa !# /bin/bashaparência. Portanto, quando executo meus scripts de shell, obtenho a versão antiga e ruim do bash que nem sequer possui matrizes associativas.

Usar /usr/bin/env bashusará a versão do bash encontrada no meu PATH. Se eu configurar meu PATH, para que/usr/local/bin/bash seja executado, essa será a base que meus scripts usarão.

É raro ver isso com o bash, mas é muito mais comum no Perl e Python:

• Algumas versões do Unix / Linux que se concentram na estabilidade às vezes estão muito atrasadas com o lançamento dessas duas linguagens de script. Há pouco tempo, o Perl do RHEL estava em 5.8.8 - uma versão de oito anos do Perl! Se alguém quisesse usar recursos mais modernos, você teria que instalar sua própria versão.
• Programas como Perlbrew e Pythonbrew permitem instalar várias versões desses idiomas. Eles dependem de scripts que manipulam seu PATH para obter a versão desejada. A codificação do caminho significa que não consigo executar meu script em preparação .
• Não faz muito tempo (tudo bem, faz muito tempo) que Perl e Python não eram pacotes padrão incluídos na maioria dos sistemas Unix. Isso significava que você não sabia onde esses dois programas foram instalados. Estava embaixo /bin? /usr/bin? /opt/bin? Quem sabe? Usar #! /usr/bin/env perlsignificava que eu não precisava saber.

E agora, por que você não deve usar #! /usr/bin/env bash

Quando o caminho é codificado no shebang, eu tenho que correr com esse intérprete. Assim, #! /bin/bashme obriga a usar a versão padrão instalada do bash. Como os recursos do bash são muito estáveis ​​(tente executar uma versão 2.x de um script Python no Python 3.x), é muito improvável que meu script BASH em particular não funcione, e como meu script bash provavelmente é usado por esse sistema e outros sistemas , o uso de uma versão não padrão do bash pode ter efeitos indesejados. É muito provável que eu queira ter certeza de que a versão padrão estável do bash seja usada com meu script de shell. Assim, eu provavelmente quero codificar o caminho no meu shebang.

Invocar bashé um pouco exagerado. A menos que você tenha vários bashbinários como o seu em ~ / bin, mas isso também significa que seu código depende de $ PATH ter as coisas certas.

É útil para coisas como isso python. Existem scripts e ambientes de wrapper que levam a pythonbinários alternativos sendo usados.

Mas nada se perde usando o caminho exato para o binário, desde que você tenha certeza de que é o binário que realmente deseja.

Existem muitos sistemas que não possuem o Bash /bin, FreeBSD e OpenBSD apenas para citar alguns. Se o seu script for portátil para muitos Unices diferentes, convém usá-lo em #!/usr/bin/env bashvez de#!/bin/bash .

Observe que isso não é verdadeiro para sh; para scripts Bourne compatíveis I exclusivamente usar #!/bin/sh, desde que eu acho que praticamente todos os Unix na existência tem shem /bin.

Eu preferiria agrupar o programa principal em um script como abaixo para verificar todos os bashdisponíveis no sistema. Melhor ter mais controle sobre a versão usada.

#! /usr/bin/env bash

# This script just chooses the appropriate bash
# installed in system and executes testcode.main

readonly DESIRED_VERSION="5"

declare all_bash_installed_on_this_system
declare bash

if [ "${BASH_VERSINFO}" -ne "${DESIRED_VERSION}" ]
then
    found=0

    all_bash_installed_on_this_system="$(\
        awk -F'/' '$NF == "bash"{print}' "/etc/shells"\
        )"

    for bash in $all_bash_installed_on_this_system
    do
        versinfo="$( $bash -c 'echo ${BASH_VERSINFO}' )"
        [ "${versinfo}" -eq "${DESIRED_VERSION}" ] && { found=1 ; break;}
    done
    if [ "${found}" -ne 1 ]
    then
        echo "${DESIRED_VERSION} not available"
        exit 1
    fi
fi

$bash main_program "$@"

 #!/usr/bin/env bash

é definitivamente melhor porque encontra o caminho executável do bash a partir da variável de ambiente do sistema.

Vá para o seu shell Linux e digite

env

Ele imprimirá todas as suas variáveis ​​de ambiente.

Vá para o seu shell script e digite

echo $BASH

Ele imprimirá o caminho do bash (de acordo com a lista de variáveis ​​de ambiente) que você deve usar para criar o caminho correto do shebang em seu script.