Dlaczego muszę „pozyskiwać plik .profile” w każdym otwartym terminalu?

Kiedy zmienimy jakąś zmienną w ~/.profileUbuntu, wówczas wykonujemy polecenie source .profile. Wtedy zmiana obowiązuje tylko w tym terminalu. Jeśli otworzymy nowy terminal, musimy source .profileponownie wykonać polecenie . Wygląda więc na to, że różne terminale mają swoje własne środowisko, chociaż mogą należeć do tego samego użytkownika.

Jakie są zalety tego, że każdy terminal ma swoją własną ścieżkę środowiska? Wydaje się, że byłoby lepiej, gdyby inny terminal należący do tego samego użytkownika współdzielił tę samą zmienną środowiskową.

Powodem tego jest to, że ~/.profilesą pozyskiwane tylko z powłok logowania. Po otwarciu nowego okna terminala uruchamiana jest domyślnie powłoka niezalogowana. Jeśli się wylogujesz i zalogujesz ponownie, zmiana na ~/.profilebędzie obowiązywać we wszystkich twoich terminalach, ponieważ ~/.profilejest pozyskiwana podczas logowania do sesji.

Nie jest tak, że różne okna terminali mają inne środowisko, ale pozyskiwanie odbywa się ~/.profiletylko ~/.profilew bieżącej powłoce (dokładnie to sourcerobi polecenie).

Natomiast zmiana na ~/.bashrcnatychmiast wpłynie na każde nowe okno terminala, które otworzysz, lub dowolną powłokę Bash, którą zaczniesz pisać bash, ponieważ jest pozyskiwana przez wszystkie interaktywne powłoki Bash.

Zmienne środowiskowe służą nie tylko preferencjom użytkownika. Są to ogólny mechanizm przekazywania różnorodnych informacji o ustawieniach od procesu nadrzędnego do procesów potomnych, które uruchamia.

Istnieje wiele przypadków, w których proces ustawia określone zmienne środowiskowe, aby wpływać tylko na procesy, które uruchamia. Na przykład skrypt może celowo zresetować ustawienia regionalne dla poleceń, które uruchamia, tak aby mógł przeanalizować dane wyjściowe z nich. Skrypty kompilacji dla wielu dużych pakietów oprogramowania używają zagnieżdżonych wywołań maketej współrzędnej za pomocą zmiennych środowiskowych. Specjalistyczne narzędzia mogą potrzebować zmiany warunków pracy innych programów, które uruchamiają, wykonując sztuczki za pomocą $ LD_PRELOAD lub $ PATH.

Jeśli coś użytkownik zrobi w innym oknie, podczas gdy długa kompilacja jest uruchomiona w innym, po prostu magicznie zmieni zmienne środowiskowe wszystkich swoich procesów za ich plecami, spowoduje szaleństwo i chaos.

Inne zmienne środowiskowe zawierają informacje o konkretnej sesji, w której uruchamiany jest proces. Programy oczekują od $ TERM opisu zestawu poleceń określonego terminala (lub emulatora terminala), z którym są połączone; sprawiając, że ogólne ustawienie dla poszczególnych użytkowników uniemożliwiłoby zalogowanie się do tego samego systemu z kilkoma różnymi rodzajami terminali. Nawet jeśli masz tylko jeden element terminala i nigdy nie logujesz się zdalnie, programy takie jak np. screenUstawiają inny $ TERM dla procesów uruchamianych w ich sesji.

Lepszym pytaniem byłoby, dlaczego używamy mechanizmu komunikacji międzyprocesowej dla ustawień preferencji użytkownika, a nie bazy danych dla poszczególnych użytkowników?

Odpowiedź: Ponieważ to działa wystarczająco dobrze i korzyści z dokonywania bazy danych dla każdego użytkownika nie są na tyle duże, że praca zmienia wszystko w użyciu że zamiast zmiennych środowiskowych byłoby zrobić.

(Mogę wymyślić bardzo niewiele ustawień preferencji, w których nie byłoby przypadków użycia, w których wygodnie byłoby je zmienić tylko na przykład w celu wykonania pojedynczego skryptu. Aby nie utracić funkcjonalności, wszystko musiałoby zostać zastąpione przez zmienne środowiskowe, co powoduje dodatkową złożoność i bardziej zdezorientowanych użytkowników).

To nie tak, że alternatywy nie istnieją . Na przykład zasoby X są na sesję wyświetlania, a nie na proces. Są one jednak trudno dostępne dla programów wiersza polecenia - a programy wiersza polecenia zwykle muszą działać dla zdalnych loginów, które nie mają nawet serwera X, z którym można się połączyć.