Dlaczego #! / Usr / bin / env bash jest lepszy od #! / Bin / bash?

Widziałem w wielu miejscach, w tym w zaleceniach na tej stronie ( jaki jest preferowany shebang Bash? ), Których należy używać #!/usr/bin/env bashprzed #!/bin/bash. Widziałem nawet jedną przedsiębiorczą osobę, która sugerowała, że ​​użycie #!/bin/bashbyło złe i funkcjonalność basha zostałaby utracona.

To powiedziawszy, używam bash w ściśle kontrolowanym środowisku testowym, w którym każdy dysk w obiegu jest zasadniczo klonem pojedynczego dysku głównego. Rozumiem argument dotyczący przenośności, choć niekoniecznie ma on zastosowanie w moim przypadku. Czy istnieje jakikolwiek inny powód, aby preferować #!/usr/bin/env bashalternatywne rozwiązania, a przy założeniu, że problemem była przenośność, czy istnieje jakiś powód, dla którego można by ją zepsuć?

#!/usr/bin/envwyszukiwania PATHdla bash, a bashnie zawsze jest /bin, szczególnie w systemach innych niż Linux. Na przykład w moim systemie OpenBSD jest on włączony/usr/local/bin , ponieważ został zainstalowany jako opcjonalny pakiet.

Jeśli jesteś absolutnie pewien, że bashjest /bini zawsze będzie, umieszczenie go bezpośrednio w swoim shebang nie zaszkodzi - ale odradzam to, ponieważ skrypty i programy mają życie dłuższe niż początkowo sądzimy, że będą.

Standardowa lokalizacja bash to /bini podejrzewam, że tak jest we wszystkich systemach. Co jednak, jeśli nie spodoba ci się ta wersja bash? Na przykład chcę użyć wersji bash 4.2, ale wersja bash na moim komputerze Mac to 3.2.5.

Mógłbym spróbować ponownie zainstalować bash, /binale to może być zły pomysł. Jeśli zaktualizuję system operacyjny, zostanie on zastąpiony.

Mogę jednak zainstalować bash /usr/local/bin/bashi skonfigurować ŚCIEŻKĘ do:

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

Teraz, jeśli sprecyzuję bash, nie dostanę starego, szorstkiego /bin/bash, ale nowszego, bardziej błyszczącego /usr/local/bin. Miły!

Tyle że moje skrypty powłoki mają ten !# /bin/bashshebang. Tak więc, kiedy uruchamiam skrypty powłoki, otrzymuję starą i kiepską wersję basha, która nawet nie ma tablic asocjacyjnych.

Użycie /usr/bin/env bashspowoduje użycie wersji bash z mojej ŚCIEŻKI. Jeśli skonfiguruję ŚCIEŻKĘ, to tak/usr/local/bin/bash została wykonana, to będzie bash, którego użyją moje skrypty.

Rzadko widuje się to podczas bash, ale jest znacznie bardziej powszechne w Perlu i Pythonie:

• Niektóre wydania Uniksa / Linuksa, które koncentrują się na stabilności, są czasem daleko w tyle za wydaniem tych dwóch języków skryptowych. Niedawno Perl RHEL miał 5,8 - ośmioletnia wersja Perla! Jeśli ktoś chciał korzystać z bardziej nowoczesnych funkcji, musiałeś zainstalować własną wersję.
• Programy takie jak Perlbrew i Pythonbrew pozwalają instalować wiele wersji tych języków. Zależą od skryptów, które manipulują ŚCIEŻKĄ, aby uzyskać żądaną wersję. Twarde kodowanie ścieżki oznacza, że ​​nie mogę uruchomić skryptu w trakcie przygotowywania .
• Nie tak dawno temu (dobrze, dawno temu) Perl i Python nie były standardowymi pakietami zawartymi w większości systemów uniksowych. Oznaczało to, że nie wiesz, gdzie zostały zainstalowane te dwa programy. Czy to było pod /bin? /usr/bin? /opt/bin? Kto wie? Używanie #! /usr/bin/env perloznaczało, że nie musiałem wiedzieć.

A teraz dlaczego nie powinieneś używać #! /usr/bin/env bash

Kiedy ścieżka jest zakodowana na sztywno, muszę biec z tym tłumaczem. W ten sposób #! /bin/bashzmusza mnie do korzystania z zainstalowanego domyślną wersję bash. Ponieważ funkcje bash są bardzo stabilne (spróbuj uruchomić wersję 2.x skryptu Python pod Pythonem 3.x), jest bardzo mało prawdopodobne, że mój konkretny skrypt BASH nie będzie działał, a ponieważ mój skrypt bash jest prawdopodobnie używany przez ten system i inne systemy , używanie niestandardowej wersji bash może mieć niepożądane skutki. Jest bardzo prawdopodobne, że chcę się upewnić, że w moim skrypcie powłoki używana jest stabilna standardowa wersja bash. Dlatego prawdopodobnie chcę mocno zakodować ścieżkę w moim shebang.

Przywoływanie bashto trochę przesada. Chyba że masz wiele bashplików binarnych, takich jak twój własny w ~ / bin, ale oznacza to również, że twój kod zależy od tego, czy $ PATH ma w sobie odpowiednie rzeczy.

Jest to przydatne przy takich rzeczach python. Istnieją skrypty opakowania i środowiska, które prowadzą do pythonużycia alternatywnych plików binarnych.

Ale nic nie jest stracone przez zastosowanie dokładnej ścieżki do pliku binarnego, o ile masz pewność, że jest to plik binarny, którego naprawdę potrzebujesz.

Istnieje wiele systemów, które nie zawierają Bash /bin, FreeBSD i OpenBSD, żeby wymienić tylko kilka. Jeśli twój skrypt ma być przenośny dla wielu różnych Uniksów, możesz użyć #!/usr/bin/env bashzamiast niego#!/bin/bash .

Zauważ, że nie dotyczy to sh; Bourne skryptów zgodnych I wyłącznie używać #!/bin/sh, ponieważ myślę, że prawie każdy ma Unix istnieje shw /bin.

Wolałbym zawinąć główny program w skrypt jak poniżej, aby sprawdzić wszystkie bashdostępne w systemie. Lepiej mieć większą kontrolę nad wersją, której używa.

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

jest zdecydowanie lepszy, ponieważ znajduje ścieżkę wykonywalną bash ze zmiennej środowiskowej systemu.

Przejdź do powłoki Linux i wpisz

env

Wydrukuje wszystkie zmienne środowiskowe.

Przejdź do skryptu powłoki i wpisz

echo $BASH

Spowoduje to wydrukowanie ścieżki bash (zgodnie z listą zmiennych środowiskowych), której należy użyć do zbudowania poprawnej ścieżki shebang w skrypcie.