Ostatnio zauważyłem, że mamy 3 opcje ustawienia zmiennych środowiskowych:
export envVar1=1setenv envVar2=2env envVAr3=3Jeśli są inne sposoby, proszę oświeć nas.
Kiedy powinienem preferować jeden od drugiego? Proszę zasugerować wytyczne.
Co do kompatybilności powłoki, która jest najbardziej ekspansywna (obejmuje więcej dialektów powłoki)?
Już zauważyłem tę odpowiedź, ale chcę rozszerzyć pytanie o envwytyczne dotyczące preferencji użytkowania.
Odpowiedzi:
export VARIABLE_NAME='some value'jest sposób ustawić zmienną w każdej powłoce POSIX ( sh, dash, bash, ksh, itp .; również zsh). Jeśli zmienna ma już wartość, możesz ją export VARIABLE_NAMEuczynić zmienną środowiskową bez zmiany jej wartości.
Powłoki Bourne w wersjach wcześniejszych niż POSIX nie obsługiwały tego, dlatego zamiast tego zobaczysz skrypty, które unikają export VARIABLE_NAME='some value'i używają VARIABLE_NAME='some value'; export VARIABLE_NAME. Ale pociski Bourne'a sprzed POSIX-u są obecnie niezwykle rzadkie.
setenv VARIABLE_NAME='some value'to składnia csh służąca do ustawiania zmiennej środowiskowej. setenvnie istnieje w sh, a csh jest niezwykle rzadko używany w skryptach i został przekroczony przez bash do interaktywnego użytku przez ostatnie 20 lat (i zsh jeszcze dłużej), więc możesz o nim zapomnieć, chyba że go spotkasz.
envKomenda jest bardzo rzadko przydatna wyjątkiem shebang linii . Po wywołaniu bez argumentów wyświetla środowisko, ale exportrobi to lepiej (posortowane i często cytowane w celu ujednoznacznienia nowych linii w wartościach od linii oddzielających wartości). Po wywołaniu z argumentami uruchamia polecenie z dodatkowymi zmiennymi środowiskowymi, ale to samo polecenie envrównież nie działa ( VAR=value mycommanddziała mycommandz VARustawionym na value, tak jak env VAR=value mycommand). Powód envjest przydatny w linii shebang, ponieważ wykonuje PATHwyszukiwanie, a przy wywołaniu z nazwą polecenia nic innego nie robi. envPolecenie może być przydatne, aby uruchomić polecenie z zaledwie kilku zmiennych środowiskowych z-ilub bez parametrów wyświetlających środowisko, w tym zmiennych o niepoprawnych nazwach, których powłoka nie importuje.
Ustawienie zmiennej takiej jak VAR='asdf'pozostawia środowisko niezmodyfikowane, co oznacza, że programy uruchamiane w tej samej sesji nic nie wiedzą VARi nie będą miały do niej dostępu. Chcesz takie zachowanie podczas pisania skryptów powłoki.
exportz drugiej strony jest wbudowanym bashem, który modyfikuje środowisko, dzięki czemu eksportowana zmienna jest widoczna dla procesów potomnych odradzających się w bieżącej sesji. Możesz osiągnąć to samo, uruchamiając VAR='asdf' %program_name%.
envnie jest wbudowany, ale sam program. Na powierzchni działa dokładnie tak, jak u ciebie VAR='asdf' %program_name%, ale na niższym poziomie sprawy stają się nieco bardziej skomplikowane. Najpierw envzostaje uruchomiony. Zmienia środowisko, a następnie wykonuje polecenie z podanymi argumentami. To samo zachowanie, które można osiągnąć we własnym kodzie za pomocą wywołania systemowego exec (3) .
setenvjest tylko exportw powłokach rodziny csh, jak podano w odpowiedzi.
Istnieje kilka pytań z odpowiedziami na to:
Różnica między zmiennymi powłoki, które są eksportowane, a tymi, które nie są bash
Jaka jest różnica w użyciu między zmiennymi powłoki a zmiennymi środowiskowymi?
(itp.)
VAR=asdfaktualizuje środowisko, jeśliVARbyło już w środowisku. (To nie było prawdą w oryginalnej powłoce Bourne'a.)