Dlaczego domyślne źródło Ubuntu ~ / .profile ~ / .bashrc?

Oto zawartość zapasów ~/.profiledostarczonych z moim 13.10 (usunięte linie komentowane):

if [ -n "$BASH_VERSION" ]; then
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Zostało to odziedziczone po Debianie, ale dlaczego Canonical zdecydował się go zatrzymać? O ile mi wiadomo, to nie jest standardowy sposób * nix i widziałem różne systemy, w których tak się nie stało, więc zakładam, że musieli mieć dobry powód. Może to powodować nieoczekiwane zachowanie podczas uruchamiania powłok logowania (takich jak na przykład sshing na maszynie), gdy użytkownik nie spodziewałby się, że to zrobi ~/.bashrc.

Jedyną korzyścią, jaką mogę wymyślić, jest to, aby nie mylić użytkownika z wieloma plikami startowymi i pozwolić im na .bashrcsamodzielną edycję i odczytanie niezależnie od typu powłoki. Jest to jednak wątpliwa zaleta, ponieważ często przydatne są różne ustawienia logowania i interaktywnych powłok, a to blokuje ci to możliwość. Ponadto powłoki logowania bardzo często nie działają w środowisku graficznym, co może powodować błędy, ostrzeżenia i problemy (o rany!) W zależności od tego, co ustawiłeś w tych plikach.

Dlaczego więc Ubuntu to robi, czego mi brakuje?

Jest to decyzja podjęta przez Debiana. Uzasadnienie tego wyjaśniono w tym bardzo ładnym poście na wiki , którego fragment jest fragmentem. Podsumowanie jest następujące: „aby upewnić się, że logowanie GUI i logowania inne niż GUI działają w ten sam sposób”:

Weźmy xdm jako przykład. Pierre pewnego dnia wraca z wakacji i odkrywa, że ​​jego administrator systemu zainstalował xdm w systemie Debian. Loguje się dobrze, a xdm czyta swój plik .xsession i uruchamia fluxboksa. Wszystko wydaje się być w porządku, dopóki nie pojawi się komunikat o błędzie w niewłaściwych lokalizacjach! Ponieważ zastępuje zmienną LANG w swoim .bash_profile, a ponieważ xdm nigdy nie czyta .bash_profile, jego zmienna LANG jest teraz ustawiona na en_US zamiast fr_CA.

Teraz naiwnym rozwiązaniem tego problemu jest to, że zamiast uruchamiać „xterm”, mógłby skonfigurować swojego menedżera okien, aby uruchamiał „xterm -ls”. Ta flaga informuje xterm, że zamiast uruchamiać normalną powłokę, powinna uruchomić powłokę logowania. W tej konfiguracji xterm spawnuje się / bin / bash, ale wstawia „- / bin / bash” (lub może „-bash”) w wektorze argumentów, więc bash działa jak powłoka logowania. Oznacza to, że za każdym razem, gdy otworzy nowy xterm, będzie czytał / etc / profile i .bash_profile (wbudowane zachowanie bash), a następnie .bashrc (ponieważ .bash_profile tak mówi). Na początku może się wydawać, że działa dobrze - jego pliki kropek nie są duże, więc nawet nie zauważa opóźnienia - ale jest bardziej subtelny problem. Uruchamia także przeglądarkę internetową bezpośrednio z menu Fluxboksa, a przeglądarka internetowa dziedziczy zmienną LANG z fluxboksa, która jest teraz ustawiona na niewłaściwe ustawienia regionalne. Więc chociaż jego Xtermy mogą być w porządku, a wszystko, co uruchamia się z jego Xtermów, może być w porządku, jego przeglądarka internetowa wciąż podaje mu strony w niewłaściwych lokalizacjach.

Więc jakie jest najlepsze rozwiązanie tego problemu? Naprawdę nie ma uniwersalnego. Lepszym rozwiązaniem jest zmodyfikowanie pliku .xsession, aby wyglądał mniej więcej tak:

[ -r /etc/profile ] && source /etc/profile
[ -r ~/.bash_profile ] && source ~/.bash_profile
xmodmap -e 'keysym Super_R = Multi_key'
xterm &
exec fluxbox

Powoduje to, że powłoka interpretująca skrypt .xsession odczytuje w / etc / profile i .bash_profile, jeśli istnieją i są czytelne, przed uruchomieniem xmodmap lub xterm lub „uruchomieniem” menedżera okien. Istnieje jednak jedna potencjalna wada tego podejścia: pod xdm powłoka odczytująca .xsession działa bez terminala sterującego. Jeśli albo / etc / profile lub .bash_profile używa komend, które zakładają obecność terminala (takich jak „fortuna” lub „stty”), te komendy mogą się nie powieść. Jest to główny powód, dla którego xdm domyślnie nie czyta tych plików. Jeśli zamierzasz zastosować to podejście, musisz upewnić się, że wszystkie polecenia w „plikach kropkowych” są bezpieczne do uruchomienia, gdy nie ma terminala.

Jest to standardowe zachowanie Ubuntu, ~/.bashrcjest to plik startowy dla powłoki interaktywnej na poziomie użytkownika. Po otwarciu terminala w zasadzie uruchamiasz interaktywną powłokę bez logowania, która odczytuje ~/.bashrczawartość ~/.bashrci jest pobierana i eksportowana do bieżącego środowiska powłoki. Pomaga uzyskać wszystkie zmienne i funkcje powłoki zdefiniowane przez użytkownika w bieżącej powłoce. Możesz także znaleźć takie linie

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

aby uzyskać zdefiniowane przez użytkownika aliasy w bieżącym środowisku powłoki.

Jest to ważne, aby zapewnić również wygodę użytkowania. Na przykład można by przechowywać proxy poświadczeń in .bashrc, chyba że się pozyskiwane żaden z wniosków końcowych ( mianowicie , ping, wget, curl, lynxitd.) Będą działać poprawnie. Lub musisz podać poświadczenia proxy za każdym razem, gdy otwierasz terminal.

Poza domyślnym Ubuntu .bashrczawiera wiele przyjaznych dla użytkownika aliasów (dla lsi grepwydrukować wyjście pokolorowany), wiele nowych definicji dla różnych zmiennych powłoki, co zwiększa wygodę użytkowników.

Ale w przypadku logowania ssh lub logowania w wirtualnej konsoli , zasadniczo otrzymujesz interaktywną powłokę logowania. Tam jest plik inicjujący powłokę ~/.profile. Dlatego jeśli nie podasz źródła ~/.bashrc, przegapisz wszystkie pomocne ustawienia w swoim .bashrc. Dlatego domyślne ~/.profileźródło Ubuntu~/.bashrc

Sprawa do uniknięcia

• nigdy nie powinieneś pozyskiwać ~/.profileformy ~/.bashrcw tym samym czasie, gdy ~/.bashrcjest pozyskiwana ~/.profile. Stworzy to nieskończoną pętlę sytuacji, w wyniku czego monit terminala zostanie zawieszony, chyba że naciśniesz Ctrl+ C. W takiej sytuacji, jeśli umieścisz linię w swoim~/.bashrc

ustaw -x

Wtedy zobaczysz, że deskryptor pliku zatrzymuje się po otwarciu terminala.