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

30

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?

terdon
źródło
Dlaczego miałoby -n "$BASH_VERSION"być prawdą poza bashiem?
Elliott Frisch
@ElliottFrisch to nie będzie. Moje pytanie brzmi: dlaczego .profileźródło .bashrc, tak nie jest we wszystkich wersjach Linuksa i zastanawiam się, jakie jest uzasadnienie.
terdon
Wygląda na to, że zostanie zaimplementowany w ten sposób w debian upstream.
Elliott Frisch
@ElliottFrisch tak, myślałem, że tak nie jest, sprawdziłem i zobaczyłem, że nadszedł czas, aby edytować mój komentarz. Niemniej jednak, nie jest tak w przypadku systemu SuSe, do którego mam dostęp (chociaż jest to CentOS) i nie było tak w przypadku różnych systemów (RH, Fedoras, starsze Ubuntus), o ile pamiętam. Zastanawiam się więc dlaczego.
terdon

Odpowiedzi:

15

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.

terdon
źródło
Nadal uważam, że to nie jest świetny pomysł. Idealnym rozwiązaniem byłoby upewnienie się, że menedżer wyświetlania pozyska profil globalny (sprawdź) i .profile powłoki użytkownika . Teraz wiem, dlaczego zduplikowałem ścieżki w niektórych zmiennych ...
Rmano
2

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.

souravc
źródło
Dzięki, to są wszystkie prawdziwe i przydatne informacje. To po prostu nie odnosi się do mojego pytania. Znam różnice między powłokami do logowania i bez logowania. Moje pytanie brzmi: dlaczego w systemach Ubuntu .profilepozyskiwanie jest .bashrc? SuSe Enterprise 10 tego nie robi, podobnie jak żadna wersja Fedory, z której korzystałem, ale to było lata temu, mogę się mylić. CentOS 5.8 robi dość dziwnie. W każdym razie, rozumiesz mój punkt widzenia? To wybór projektowy i zastanawiam się, dlaczego został wykonany.
terdon
Nie korzystałem rygorystycznie z innych dystrybucji Linuksa, które wymieniłeś. czy możesz mi powiedzieć, jak radzą sobie z sytuacjami takimi jak polecenia aliasy w sesji ssh, które są zdefiniowane w .bashrclub w .bash_aliases. Na przykład mam pseudonim, lsjak ls --color=autow moim, .bashrci .bashrcotrzymałem od siebie .profile. Tutaj mogę używać aliasu nawet z ssh. Lub mógłbym użyć proxy w sesji ssh. Jeśli nie źródłowy mojej .bashrcz .profilestracę te cechy. Myślę, że chodzi o lepszą obsługę.
souravc
Nie, te aliasy nie będą działać. I tak, zaopatrzenie to .bashrcrozwiązuje. Ale to także powoduje problemy. Pamiętam, że kiedy po raz pierwszy użyłem systemu, który miał takie zachowanie, ciągle otrzymywałem te dziwne komunikaty ssh, ponieważ korzystałem xset b offz niego, .bashrcktóry wyłączał dzwonek terminala, ale tylko w systemie X, więc podawał komunikaty o błędach. Wieki zajęło mi ustalenie, co się dzieje, ponieważ nie sądziłem, że .bashrczostanie to odczytane podczas uruchamiania powłoki logowania. Zastanawiam się tylko, czy istnieje na ten temat „oficjalne” oświadczenie.
terdon
Zgadzam się z Tobą. Wcześniej miałem również problemy . Ale jest to przede wszystkim pomocne i przyjazne dla użytkownika, jeśli weźmiesz pod uwagę i unikniesz kilku specjalnych przypadków. Czyż nie :)
souravc
Tak, istnieją uzasadnione powody. Byłem ciekawy, czy firma Canonical kiedykolwiek uzasadniła utrzymanie tej wcześniejszej decyzji.
terdon