sposób na sprawdzenie bieżącej powłoki zgodny z checkbashisms

W moim .profile używam następującego kodu, aby upewnić się, że aliasy i funkcje związane z Bash są pozyskiwane tylko wtedy, gdy powłoką logowania jest Bash :

# If the current (login) shell is Bash, then
if [ "${BASH_VERSION:-}" ]; then
  # source ~/.bashrc if it exists.
  if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
  fi
fi

Obecnie jestem w trakcie kontroli plików konfiguracyjnych powłoki, skryptów i funkcji pod kontrolą wersji. Ja również niedawno rozpoczęła proces usuwania przypadkowych Bashisms ze skryptów powłoki, które nie korzystają z Bash-specyficzne cechy, np wymianie function funcname()z funcname().

Dla mojego repozytorium plików powłoki skonfigurowałem hak wstępnego zatwierdzania, który uruchamia checkbashismsnarzędzie z pakietu devscripts Debiana na każdymsh pliku w repozytorium, aby upewnić się, że nie wprowadzę przypadkowo składni specyficznej dla Bash. Rodzi to jednak błąd dla mojego .profile:

possible bashism in .profile line 51 ($BASH_SOMETHING):
if [ "${BASH_VERSION:-}" ]; then

Zastanawiałem się, czy istnieje sposób sprawdzenia, która powłoka jest uruchomiona, co nie wywołałoby ostrzeżenia checkbashisms.

Sprawdziłem listę zmiennych związanych powłoką wymienionych przez POSIX w nadziei, że jedna z nich mogłaby posłużyć do wyświetlenia bieżącej powłoki. Przyjrzałem się również zmiennym ustawionym w interaktywnej powłoce Dash, ale znowu nie udało mi się znaleźć odpowiedniego kandydata.

W tej chwili wykluczyłem .profileprzetwarzanie checkbashisms; to mały plik, więc nie jest trudno go sprawdzić ręcznie. Jednak po zbadaniu problemu nadal chciałbym wiedzieć, czy istnieje metoda zgodna z POSIX, aby określić, która powłoka działa (lub przynajmniej sposób, który nie powoduje checkbashismsawarii).

Dalsze informacje / wyjaśnienia

Jednym z powodów, dla których poddaję pliki konfiguracyjne powłoki kontroli wersji, jest konfiguracja środowiska we wszystkich systemach, na których obecnie loguję się regularnie: Cygwin, Ubuntu i CentOS (zarówno 5, jak i 7, używając Active Directory dla użytkownika poświadczenie). Najczęściej loguję się za pośrednictwem środowisk X Windows / Desktop i SSH dla hostów zdalnych. Chciałbym jednak, aby był to dowód na przyszłość i jak najmniej polegał na zależnościach systemu i innych narzędziach.

Używam checkbashismsjako prostego, automatycznego sprawdzania poprawności składni plików związanych z powłoką. Nie jest to idealne narzędzie, np. Już nałożyłem na niego łatkę, aby nie narzekała na użycie command -vw moich skryptach. Podczas badań dowiedziałem się, że rzeczywistym celem programu jest zapewnienie zgodności z polityką Debiana, która, jak rozumiem, opiera się na POSIX 2004, a nie na 2008 (lub jego wersji z 2013 roku).

Twój

# If the current (login) shell is Bash, then
if [ "${BASH_VERSION:-}" ]; then
  # source ~/.bashrc if it exists.
  if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
  fi
fi

kod jest całkowicie zgodny z POSIX i jest to najlepszy sposób na sprawdzenie, czy aktualnie działasz bash. Oczywiście $BASH_VERSIONzmienna jest specyficzna dla basha, ale właśnie dlatego jej używasz! Aby sprawdzić, czy biegnieszbash !

Pamiętaj, że $BASH_VERSIONzostanie ustawione, czy bashbędzie wywoływane jako bashczy sh. Po upewnieniu się, że działasz bash, możesz użyć [ -o posix ]jako wskaźnika, że ​​powłoka została wywołana jako sh(chociaż ta opcja jest również ustawiona, gdy POSIXLY_CORRECT znajduje się w środowisku lub bashjest wywoływane z -o posix, lub z SHELLOPTS = posix w środowisku. Ale we wszystkich tych przypadkach bashzachowuje się tak, jakby był nazywany jak sh).

Inna zmienna, której możesz użyć zamiast $BASH_VERSIONi checkbashismwydaje się, że nie narzeka, chyba że zostanie podana -xopcja $BASH. Jest to również specyficzne dla bashtego, z którego powinieneś być w stanie określić, czy biegasz, bashczy nie.

Twierdziłbym również, że tak naprawdę nie jest to właściwe użycie checkbashisms. checkbashismsjest narzędziem pomagającym pisać przenośne shskrypty (zgodnie ze shspecyfikacją w polityce Debiana, nadzbiorem POSIX), pomaga zidentyfikować niestandardową składnię wprowadzoną przez osoby piszące skrypty w systemach, w których shznajduje się dowiązanie symboliczne dobash .

A .profilejest interpretowane przez różne powłoki, z których wiele nie jest zgodnych z POSIX. Ogólnie rzecz biorąc, nie należy używać shjako powłokę logowania, ale muszle podoba zsh, fishczy bashz bardziej zaawansowanych funkcji interaktywnych.

bashi zshgdy nie są wywoływane jako shi kiedy ich odpowiedni plik sesji profilu ( .bash_profile, .zprofile) nie jest zgodny z POSIX (szczególnie zsh), ale nadal jest czytany .profile.

Więc nie jest to składnia POSIX, którą chcesz, .profileale składnia zgodna z POSIX (dla sh), basha zshjeśli kiedykolwiek będziesz używać tych powłok (być może nawet Bourne, ponieważ powłoka Bourne również czyta, .profileale nie jest powszechnie spotykana w systemach Linux) ).

checkbashismsna pewno pomogłoby ci znaleźć baszty, ale może nie wskazywać składni POSIX, która nie jest kompatybilna z zshlubbash .

Tutaj, jeśli chcesz użyć bashkodu -specyficznego (jak obejście tego bashbłędu, dzięki któremu nie czyta się ~/.bashrcw interaktywnych powłokach logowania), lepszym rozwiązaniem byłoby to ~/.bash_profilezrobić (przed lub po sourcowaniu, ~/.profilegdzie umieszczasz swoją wspólną sesję inicjalizacje).

Zwykle używa się $0do tego celu. Na stronie, którą podlinkowałeś, stoi:

0
   (Zero.) Expands to the name of the shell or shell script.

Zwykle zmienna środowiskowa SHELL informuje o domyślnej powłoce. Nie powinno być konieczne ręczne źródło pliku .bashrc (nieprawda, patrz aktualizacja poniżej), bash powinien to zrobić automatycznie, po prostu upewnij się, że znajduje się on w katalogu $ HOME.

Inną opcją jest zrobienie czegoś takiego:

 ps -o cmd= $$

która powie ci polecenie (bez argumentów, = bez wartości nie wyświetli nagłówków kolumn) bieżącego procesu. Przykładowe dane wyjściowe:

 $ps -o cmd= $$
 bash
 $sh
 $ps -o cmd= $$
 sh

AKTUALIZACJA:

Poprawiono mnie! :)

Plik .bashrc nie zawsze jest pozyskiwany, jak wspomniano w komentarzach poniżej /programming/415403/whats-the-difference-between-bashrc-bash-profile-and-environment

Możesz więc przenieść .bashrc do .bash_profile i sprawdzić, czy to działa bez konieczności wykonywania testu. Jeśli nie, masz powyższy test.

Pytanie dotyczy powłoki logowania użytkownika oraz bieżącej powłoki w sposób, który uspokaja checkbashisms. Jeśli ma to być powłoka, na której zalogował się użytkownik, użyłbym tej z /etc/passwdnp.

MY_UID=$(id -u)
MYSHELL=$(awk -F: '$3 == '$MY_UID'{ print $7; }' </etc/passwd )

Użytkownicy mogą oczywiście uruchomić nową powłokę po zalogowaniu. Oczywiście, jeśli jedna jest bash, a druga nie, testy zmiennych środowiskowych bash mogą nie pomóc.

Niektórzy mogą chcieć użyć getentzamiast passwdpliku (ale nie byłoby to objęte pytaniem).

W oparciu o komentarz na temat LDAP i sugestię lognamemożna użyć tej alternatywnej formy:

MY_NAME=$(logname)
MYSHELL=$(getent passwd | awk -F: '$1 ~ /^'$MY_NAME'$/ {print $7;}' )

Podczas testowania zauważyłem, że lognamenie podoba mi się przekierowanie danych wejściowych (więc zostawiłem wyrażenie podzielone). Pokazy szybkiej kontroli getentpowinny działać na wymienionych platformach (choć powinno to być zawarte w pierwotnym pytaniu):

• Nowy pakiet: getent-2.18.90-1
• Uwierzytelnij SSHD RHEL 5 i 6 za pomocą protokołu Kerberos i LDAP w usłudze Active Directory w systemie Windows Server 2008 R2
• getent - pobierz wpisy z administracyjnej bazy danych (Ubuntu)