Dlaczego lepiej używać „#! / Usr / bin / env NAME” zamiast „#! / Path / to / NAME” jako mojego shebang?

Zauważam, że niektóre skrypty, które nabyłem od innych, mają shebang, #!/path/to/NAMEpodczas gdy inne (używając tego samego narzędzia, NAME) mają shebang #!/usr/bin/env NAME.

Oba wydają się działać poprawnie. W samouczkach (na przykład w języku Python) wydaje się, że istnieje sugestia, że ​​ten ostatni shebang jest lepszy. Ale nie do końca rozumiem, dlaczego tak jest.

Zdaję sobie sprawę z tego, że aby użyć tego ostatniego szangletu, NAZWA musi znajdować się w ŚCIEŻCE, podczas gdy pierwszy szejk nie ma tego ograniczenia.

Wydaje mi się także (dla mnie), że pierwszy byłby lepszym shebangiem, ponieważ precyzuje dokładnie, gdzie znajduje się NAME. W takim przypadku, jeśli istnieje wiele wersji NAME (np. / Usr / bin / NAME, / usr / local / bin / NAME), pierwszy przypadek określa, którego użyć.

Moje pytanie brzmi: dlaczego pierwszy shebang jest lepszy od drugiego?

To niekoniecznie lepsze.

Zaletą #!/usr/bin/env pythonjest to, że użyje dowolnego pythonpliku wykonywalnego, który pojawi się jako pierwszy w użytkowniku $PATH.

Wadą z #!/usr/bin/env pythonjest to, że będzie używać cokolwiek pythonwykonywalny pierwszy pojawia się w instrukcji $PATH.

Oznacza to, że skrypt może zachowywać się inaczej w zależności od tego, kto go uruchamia. W przypadku jednego użytkownika może korzystać z /usr/bin/pythonzainstalowanego z systemem operacyjnym. Po drugie, może użyć eksperymentu /home/phred/bin/python, który nie działa poprawnie.

A jeśli pythonjest zainstalowany tylko /usr/local/binużytkownik, który nie ma /usr/local/binna $PATHnie nawet w stanie uruchomić skrypt. (Prawdopodobnie nie jest to zbyt prawdopodobne w nowoczesnych systemach, ale może się to zdarzyć w przypadku bardziej niejasnego tłumacza.)

Określając #!/usr/bin/python, dokładnie określasz, który interpreter będzie używany do uruchomienia skryptu w określonym systemie .

Innym potencjalnym problemem jest to, że #!/usr/bin/envsztuczka nie pozwala ci przekazywać argumentów do interentera (innych niż nazwa skryptu, która jest przekazywana niejawnie). To zwykle nie jest problemem, ale może być. Wiele skryptów Perla jest napisanych przy użyciu #!/usr/bin/perl -w, ale obecnie use warnings;jest to zalecany zamiennik. Skrypty #!/bin/csh -fcsh powinny być używane - ale skrypty csh nie są zalecane . Ale mogą być inne przykłady.

Mam wiele skryptów Perla w osobistym systemie kontroli źródła, które instaluję, kiedy zakładam konto w nowym systemie. Używam skryptu instalatora, który modyfikuje #!wiersz każdego skryptu, gdy instaluje go w moim $HOME/bin. (Nie musiałem używać niczego innego niż #!/usr/bin/perlostatnio; to sięga czasów, gdy Perl często nie był domyślnie instalowany).

Drobna uwaga: #!/usr/bin/envsztuczka jest prawdopodobnie nadużyciem envpolecenia, które pierwotnie miało (jak sama nazwa wskazuje) wywoływać polecenie w zmienionym środowisku. Ponadto niektóre starsze systemy (w tym SunOS 4, jeśli dobrze pamiętam) nie miały tego envpolecenia /usr/bin. Żaden z nich prawdopodobnie nie będzie stanowić poważnego problemu. envdziała w ten sposób, wiele skryptów używa tej #!/usr/bin/envsztuczki, a dostawcy systemów operacyjnych prawdopodobnie nie zrobią nic, aby ją złamać. Może to być problem, jeśli chcesz, aby skrypt działał na naprawdę starym systemie, ale prawdopodobnie i tak będziesz musiał go zmodyfikować.

Innym możliwym problemem (dzięki Sopalajo de Arrierez za wskazanie tego w komentarzach) jest to, że zadania cron działają w ograniczonym środowisku. W szczególności $PATHjest to zwykle coś w rodzaju /usr/bin:/bin. Więc jeśli katalog zawierający interpreter nie znajduje się w jednym z tych katalogów, nawet jeśli jest domyślnie $PATHw powłoce użytkownika, /usr/bin/envsztuczka nie zadziała. Możesz podać dokładną ścieżkę lub dodać linię do swojego crontab, aby ustawić $PATH( man 5 crontabszczegółowe informacje).

Ponieważ / usr / bin / env może interpretować twoje $PATH, co czyni skrypty bardziej przenośnymi.

#!/usr/local/bin/python

Uruchomi skrypt tylko, jeśli Python jest zainstalowany w / usr / local / bin.

#!/usr/bin/env python

Zinterpretuje twój $PATHi znajdzie python w dowolnym katalogu w twoim $PATH.

Więc twój skrypt jest bardziej mobilny i będzie działać bez żadnych modyfikacji w systemach, w których zainstalowany jest jak pyton /usr/bin/python, lub /usr/local/bin/python, lub nawet niestandardowych katalogów (które zostały dodane do $PATH), jak /opt/local/bin/python.

Przenośność jest jedynym powodem, dla którego użycie envjest preferowane zamiast ścieżek zakodowanych na stałe.

Określenie ścieżki bezwzględnej jest bardziej precyzyjne w danym systemie. Minusem jest to, że jest zbyt precyzyjne. Załóżmy, że zdajesz sobie sprawę, że systemowa instalacja Perla jest zbyt stara dla twoich skryptów i zamiast tego chcesz użyć własnej: wtedy musisz edytować skrypty i zmienić #!/usr/bin/perlna #!/home/myname/bin/perl. Co gorsza, jeśli masz Perla /usr/binna niektórych komputerach, /usr/local/binna innych i /home/myname/bin/perljeszcze na innych komputerach, będziesz musiał zachować trzy osobne kopie skryptów i wykonać odpowiedni na każdym komputerze.

#!/usr/bin/envpsuje się, jeśli PATHjest źle, ale robi prawie wszystko. Próba działania ze złym PATHjest bardzo rzadko przydatna i wskazuje, że wiesz bardzo mało o systemie, w którym działa skrypt, więc nie możesz polegać na żadnej bezwzględnej ścieżce.

Istnieją dwa programy, w których lokalizacji można polegać na prawie każdym wariancie uniksowym: /bin/shi /usr/bin/env. Niektóre niejasne i przeważnie wycofane warianty uniksowe miały je /bin/envbez /usr/bin/env, ale raczej ich nie spotkasz. Nowoczesne systemy mają /usr/bin/envwłaśnie swoje szerokie zastosowanie w shebangach. /usr/bin/envjest coś, na co możesz liczyć.

Poza /bin/shtym jedyną sytuacją, w której powinieneś użyć bezwzględnej ścieżki w shebang, jest to, że twój skrypt nie ma być przenośny, więc możesz liczyć na znaną lokalizację dla tłumacza. Na przykład można bezpiecznie używać skryptu bash, który działa tylko w systemie Linux #!/bin/bash. Skrypt przeznaczony wyłącznie do użytku wewnętrznego może polegać na konwencjach lokalizacji interpretera domowego.

#!/usr/bin/envma wady. Jest bardziej elastyczny niż określenie ścieżki bezwzględnej, ale nadal wymaga znajomości nazwy tłumacza. Czasami możesz chcieć uruchomić interpreter, którego nie ma $PATH, na przykład w lokalizacji względem skryptu. W takich przypadkach często można utworzyć skrypt poliglota, który może być interpretowany zarówno przez standardową powłokę, jak i przez żądanego tłumacza. Na przykład, aby uczynić skrypt Python 2 przenośnym zarówno dla systemów, w których pythonjest Python 3 i python2Python 2, jak i dla systemów, w których pythonPython 2 i python2nie istnieje:

#!/bin/sh
''':'
if type python2 >/dev/null 2>/dev/null; then
  exec python2 "$0" "$@"
else
  exec python "$0" "$@"
fi
'''
# real Python script starts here
def …

Używanie w Perlu #!/usr/bin/envjest złym pomysłem z dwóch powodów.

Po pierwsze, nie jest przenośny. Na niektórych niejasnych platformach env nie znajduje się w / usr / bin. Po drugie, jak zauważył Keith Thompson , może powodować problemy z przekazywaniem argumentów w linii shebang. Maksymalnie przenośne rozwiązanie to:

#!/bin/sh
exec perl -x "$0" "$@"
#!perl

Aby uzyskać szczegółowe informacje na temat tego, jak to działa, zobacz „perldoc perlrun” i co mówi o argumencie -x.

Różnica między nimi wynika z tego, w jaki sposób skrypty są wykonywane.

Użycie /usr/bin/env(które, jak wspomniano w innych odpowiedziach, nie jest dostępne w /usr/binniektórych systemach operacyjnych) jest wymagane, ponieważ nie można po prostu umieścić nazwy pliku wykonywalnego po #!- musi to być ścieżka bezwzględna. Wynika to z faktu, że #!mechanizm działa na niższym poziomie niż powłoka. Jest częścią binarnego modułu ładującego jądra. Można to przetestować. Umieść to w pliku i zaznacz jako plik wykonywalny:

#!bash

echo 'foo'

Przekonasz się, że drukuje taki błąd podczas próby uruchomienia:

Failed to execute process './test.sh'. Reason:
The file './test.sh' does not exist or could not be executed.

Jeśli plik jest oznaczony jako wykonywalny i zaczyna się od a #!, jądro (które nie wie o tym $PATHlub o bieżącym katalogu: są to koncepcje użytkownika-użytkownika) szuka pliku przy użyciu bezwzględnej ścieżki. Ponieważ używanie ścieżki bezwzględnej jest problematyczne (jak wspomniano w innych odpowiedziach), ktoś wpadł na podstęp: możesz uruchomić /usr/bin/env(który prawie zawsze jest w tej lokalizacji), aby uruchomić coś przy użyciu $PATH.

Istnieją jeszcze dwa problemy z używaniem #!/usr/bin/env

1. Nie rozwiązuje problemu określenia pełnej ścieżki do tłumacza, po prostu ją przenosi env.

   envwięcej nie gwarantuje się w /usr/bin/envniż bashjest gwarancją w /bin/bashlub w pyton /usr/bin/python.

2. env zastępuje ARGV [0] nazwą interpretera (np. bash lub python).

   Zapobiega to pojawianiu się nazwy skryptu np. W psdanych wyjściowych (lub zmienia sposób / gdzie pojawia się) i uniemożliwia znalezienie go za pomocą np.ps -C scriptname.sh

[aktualizacja 2016-06-04]

I trzeci problem:

3. Zmiana ŚCIEŻKI to więcej pracy niż tylko edytowanie pierwszego wiersza skryptu, szczególnie gdy skryptowanie takich edycji jest banalne. na przykład:

   printf "%s\n" 1 i '#!'$(type -P python2) . w | ed foo.py

   Dołączanie lub oczekiwanie na katalog do $ PATH jest dość łatwe (chociaż nadal musisz edytować plik, aby stał się trwały - twój ~/.profilelub cokolwiek innego - i daleko mu do łatwego skryptu TEGO edytowania, ponieważ PATH można ustawić w dowolnym miejscu skryptu , nie w pierwszym wierszu).

   Zmiana kolejności katalogów PATH jest znacznie trudniejsza ... i znacznie trudniejsza niż tylko edycja #!wiersza.

   I nadal masz wszystkie inne problemy, które #!/usr/bin/envdaje ci używanie .

   @jlliagre sugeruje w komentarzu #!/usr/bin/envprzydatnym do testowania skryptu z wieloma wersjami interpreterów, „zmieniając tylko ich kolejność ŚCIEŻKA / ŚCIEŻKA”

   Jeśli musisz to zrobić, o wiele łatwiej jest po prostu mieć kilka #!wierszy u góry skryptu (są to tylko komentarze w dowolnym miejscu, ale nie pierwszy wiersz) i wyciąć / skopiować i wkleić ten, którego chcesz teraz użyć, aby pierwsza linia.

   W vito byłoby tak proste, jak przesunięcie kursora do żądanej #!linii, a następnie wpisanie dd1GPlub Y1GP. Nawet przy tak trywialnym edytorze nanoużycie myszki do skopiowania i wklejenia zajęłoby kilka sekund.

Ogólnie rzecz biorąc, zalety korzystania #!/usr/bin/envsą w najlepszym razie minimalne, a na pewno nie są nawet większe niż wady. Nawet przewaga „wygody” jest w dużej mierze iluzoryczna.

IMO, to głupi pomysł promowany przez pewnego rodzaju programistę, który uważa, że ​​systemy operacyjne nie są czymś, z czym można pracować, są problemem, który należy obejść (lub w najlepszym razie zignorować).

PS: oto prosty skrypt do zmiany interpretera wielu plików jednocześnie.

change-shebang.sh:

#!/bin/bash

interpreter="$1"
shift

if [ -z "$(type -P $interpreter)" ] ; then
  echo "Error: '$interpreter' is not executable." >&2
  exit 1
fi

if [ ! -d "$interpreter" ] && [ -x "$interpreter" ] ; then
  shebang='#!'"$(realpath -e $interpreter)" || exit 1
else
  shebang='#!'"$(type -P $interpreter)"
fi

for f in "$@" ; do
  printf "%s\n" 1 i "$shebang" . w | ed "$f"
done

Uruchom jako np. change-shebang.sh python2.7 *.pyLubchange-shebang.sh $HOME/bin/my-experimental-ruby *.rb

Dodając kolejny przykład tutaj:

Korzystanie envjest również przydatne, gdy na przykład chcesz udostępniać skrypty między wieloma rvmśrodowiskami.

Uruchomienie tego w wierszu cmd pokazuje, która wersja Ruby będzie używana, gdy #!/usr/bin/env rubyzostanie użyta w skrypcie:

env ruby --version

Dlatego, kiedy używasz env, możesz używać różnych wersji Ruby przez rvm, bez zmiany skryptów.

Jeśli piszesz wyłącznie dla siebie lub dla swojej pracy, a lokalizacja tłumacza jest zawsze w tym samym miejscu, skorzystaj z bezpośredniej ścieżki. We wszystkich innych przypadkach użyj #!/usr/bin/env.

Oto dlaczego: w twojej sytuacji pythontłumacz był w tym samym miejscu, niezależnie od użytej składni, ale dla wielu osób mógł być zainstalowany w innym miejscu. Chociaż większość głównych tłumaczy programistycznych znajduje się w /usr/bin/wielu nowszych programach domyślnie /usr/local/bin/.

Chciałbym nawet argumentować, aby zawsze używać, #!/usr/bin/envponieważ jeśli masz wiele wersji tego samego interpretera i nie wiesz, jakie ustawienia domyślne ma twoja powłoka, prawdopodobnie powinieneś to naprawić.

Ze względu na przenośność i kompatybilność lepiej jest używać

#!/usr/bin/env bash

zamiast

#!/usr/bin/bash

Istnieje wiele możliwości, gdzie plik binarny może znajdować się w systemie Linux / Unix. Sprawdź stronę podręcznika hier (7), aby uzyskać szczegółowy opis hierarchii systemu plików.

Na przykład FreeBSD instaluje całe oprogramowanie, które nie jest częścią systemu podstawowego, w / usr / local / . Ponieważ bash nie jest częścią systemu podstawowego, plik bash jest instalowany w / usr / local / bin / bash .

Jeśli chcesz mieć przenośny skrypt bash / csh / perl / cokolwiek, który działa pod większością dystrybucji Linuksa i FreeBSD, powinieneś użyć #! / Usr / bin / env .

Zauważ też, że większość instalacji Linuksa również (twardo) połączyła plik binarny env z / bin / env lub linkami / usr / bin do / bin, które nie powinny być używane w shebang. Więc nie używaj #! / Bin / env .