Warum ist #! / Usr / bin / env bash #! / Bin / bash überlegen?

Ich habe an einer Reihe von Stellen gesehen, einschließlich Empfehlungen auf dieser Website ( Was ist der bevorzugte Bash Shebang? ), Um#!/usr/bin/env bash bevorzugt zu verwenden #!/bin/bash. Ich habe sogar ein unternehmender Einzel gesehen empfehlen die Verwendung #!/bin/bashwar falsch und bash Funktionalität würde , indem Sie so verloren.

Trotzdem verwende ich bash in einer streng kontrollierten Testumgebung, in der jedes im Umlauf befindliche Laufwerk im Wesentlichen ein Klon eines einzelnen Master-Laufwerks ist. Ich verstehe das Portabilitätsargument, obwohl es in meinem Fall nicht unbedingt anwendbar ist. Gibt es einen anderen Grund, #!/usr/bin/env bashden Alternativen den Vorzug zu geben, und gibt es einen Grund, der die Funktionalität beeinträchtigen könnte, wenn die Portabilität ein Problem darstellt?

#!/usr/bin/envsucht PATHnach bashund bashist nicht immer in /bin, insbesondere auf Nicht-Linux-Systemen. Auf meinem OpenBSD-System ist es beispielsweise in /usr/local/bin, da es als optionales Paket installiert wurde.

Wenn Sie absolut sicher bashsind /bin, dass dies der Fall ist und es immer sein wird, kann es nicht schaden, es direkt in Ihren Shebang zu setzen - aber ich würde es ablehnen, da Skripte und Programme alle ein Leben haben, das über das hinausgeht, was wir ursprünglich angenommen haben.

Der Standardspeicherort für Bash ist /bin, und ich vermute, dass dies auf allen Systemen zutrifft. Was ist jedoch, wenn Ihnen diese Version von Bash nicht gefällt? Zum Beispiel möchte ich Bash 4.2 verwenden, aber der Bash auf meinem Mac ist bei 3.2.5.

Ich könnte versuchen, bash neu zu installieren, /binaber das könnte eine schlechte Idee sein. Wenn ich mein Betriebssystem aktualisiere, wird es überschrieben.

Ich könnte jedoch bash in installieren /usr/local/bin/bashund meinen PATH wie folgt einrichten:

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

Wenn ich jetzt spezifiziere bash, bekomme ich nicht den alten /bin/bash, sondern den neueren, glänzenderen /usr/local/bin. Nett!

Außer meine Shell-Skripte haben diesen !# /bin/bashSchebang. Wenn ich also meine Shell-Skripte ausführe, erhalte ich diese alte und miese Version von Bash, die nicht einmal assoziative Arrays enthält.

Mit /usr/bin/env bashwird die in meinem PATH gefundene Bash-Version verwendet. Wenn ich meinen PATH so einrichte, dass er /usr/local/bin/bashausgeführt wird, ist dies die Bash, die meine Skripte verwenden.

Es ist selten, dies bei Bash zu sehen, aber es ist viel häufiger bei Perl und Python:

• Bestimmte Unix / Linux-Versionen, die sich auf Stabilität konzentrieren, liegen mit der Veröffentlichung dieser beiden Skriptsprachen manchmal weit zurück. Vor nicht allzu langer Zeit war RHELs Perl bei 5.8.8 - eine acht Jahre alte Version von Perl! Wenn jemand modernere Funktionen verwenden wollte, musste er seine eigene Version installieren.
• Mit Programmen wie Perlbrew und Pythonbrew können Sie mehrere Versionen dieser Sprachen installieren. Sie hängen von Skripten ab, die Ihren PFAD manipulieren, um die gewünschte Version zu erhalten. Wenn Sie den Pfad hart codieren, kann ich mein Skript nicht unter Brew ausführen .
• Es ist noch nicht so lange her (okay, es ist lange her), dass Perl und Python keine Standardpakete waren, die in den meisten Unix-Systemen enthalten waren. Das bedeutete, dass Sie nicht wussten, wo diese beiden Programme installiert waren. War es unter /bin? /usr/bin? /opt/bin? Wer weiß? Verwenden #! /usr/bin/env perlbedeutete, dass ich es nicht wissen musste.

Und jetzt, warum Sie nicht verwenden sollten #! /usr/bin/env bash

Wenn der Pfad im Shebang fest codiert ist, muss ich mit diesem Dolmetscher laufen. Daher #! /bin/bashzwinge ich mich, die standardmäßig installierte Version von bash zu verwenden. Da die Bash-Funktionen sehr stabil sind (versuchen Sie, eine 2.x-Version eines Python-Skripts unter Python 3.x auszuführen), ist es sehr unwahrscheinlich, dass mein spezielles BASH-Skript nicht funktioniert, und da mein Bash-Skript wahrscheinlich von diesem System und anderen Systemen verwendet wird Die Verwendung einer nicht standardmäßigen Version von Bash kann unerwünschte Auswirkungen haben. Es ist sehr wahrscheinlich, dass ich sicherstellen möchte, dass die stabile Standardversion von bash mit meinem Shell-Skript verwendet wird. Daher möchte ich wahrscheinlich den Pfad in meinem Shebang hart codieren.

Zum Aufrufen ist bashes ein bisschen übertrieben. Es sei denn, Sie haben mehrere bashBinärdateien wie Ihre eigene in ~ / bin, aber das bedeutet auch, dass Ihr Code davon abhängt, dass $ PATH die richtigen Dinge enthält.

Es ist praktisch für Dinge wie python. Es gibt Wrapper-Skripte und -Umgebungen, die dazu führen, dass alternative pythonBinärdateien verwendet werden.

Wenn Sie jedoch den genauen Pfad zur Binärdatei verwenden, geht nichts verloren, solange Sie sicher sind, dass es sich um die Binärdatei handelt, die Sie wirklich möchten.

Es gibt viele Systeme ohne Bash /bin, FreeBSD und OpenBSD, um nur einige zu nennen. Wenn Ihr Skript auf viele verschiedene Unices portierbar sein soll, möchten Sie es möglicherweise #!/usr/bin/env bashanstelle von verwenden #!/bin/bash.

Beachten Sie, dass dies nicht gilt für sh; für Bourne-kompatible Skripte ausschließlich verwende ich #!/bin/sh, da ich in Existenz so ziemlich jedes Unix denken hat shin /bin.

Ich würde es vorziehen, das Hauptprogramm in ein Skript wie das folgende zu packen, um alle bashauf dem System verfügbaren zu überprüfen . Besser mehr Kontrolle über die verwendete Version.

#! /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

ist definitiv besser, weil es den ausführbaren Pfad von bash aus Ihrer Systemumgebungsvariablen findet.

Gehen Sie zu Ihrer Linux-Shell und geben Sie ein

env

Es werden alle Ihre Umgebungsvariablen gedruckt.

Gehen Sie zu Ihrem Shell-Skript und geben Sie ein

echo $BASH

Es wird Ihr Bash-Pfad (gemäß der Liste der Umgebungsvariablen) gedruckt, den Sie verwenden sollten, um Ihren korrekten Shebang-Pfad in Ihrem Skript zu erstellen.