Jaka jest różnica między .bashrc
i .bash_profile
a których jeden należy użyć?
bash
bashrc
.bash-profile
cfischer
źródło
źródło
.profile
, spójrz na to pytanie: superuser.com/questions/789448/…Odpowiedzi:
Tradycyjnie, gdy logujesz się do systemu uniksowego, system uruchamia jeden program dla ciebie. Ten program jest powłoką, tj. Programem przeznaczonym do uruchamiania innych programów. To powłoka wiersza poleceń: uruchamiasz inny program, wpisując jego nazwę. Domyślna powłoka, powłoka Bourne'a, odczytuje polecenia z
~/.profile
momentu jej wywołania jako powłoki logowania.Bash to skorupa przypominająca Bourne'a. Odczytuje polecenia z
~/.bash_profile
momentu wywołania jako powłoki logowania, a jeśli ten plik nie istnieje¹,~/.profile
zamiast tego próbuje odczytać .Możesz wywołać powłokę bezpośrednio w dowolnym momencie, na przykład uruchamiając emulator terminala w środowisku GUI. Jeśli powłoka nie jest powłoką logowania, nie czyta
~/.profile
. Kiedy zaczynasz bash jako interaktywną powłokę (tj. Nie uruchamiać skryptu), czyta~/.bashrc
(z wyjątkiem gdy jest wywoływany jako powłoka logowania, wtedy tylko czyta~/.bash_profile
lub~/.profile
.W związku z tym:
~/.profile
to miejsce, w którym można umieścić rzeczy, które dotyczą całej sesji, takie jak programy, które chcesz uruchomić po zalogowaniu (ale nie programy graficzne, przechodzą do innego pliku) oraz definicje zmiennych środowiskowych.~/.bashrc
jest miejscem do umieszczania rzeczy, które dotyczą tylko samego basha, takich jak aliasy i definicje funkcji, opcje powłoki i ustawienia zachęty. (Możesz także umieścić tam przypisania klawiszy, ale zwykle używa się ich do bash~/.inputrc
).~/.bash_profile
może być użyte zamiast~/.profile
, ale jest odczytywane tylko przez bash, a nie przez żadną inną powłokę. (Jest to głównie problem, jeśli chcesz, aby pliki inicjujące działały na wielu komputerach, a twoja powłoka logowania nie jest bash na wszystkich z nich.) Jest to logiczne miejsce do włączenia,~/.bashrc
jeśli powłoka jest interaktywna. Polecam następujące treści w~/.bash_profile
:W nowoczesnych jednorożcach występuje dodatkowa komplikacja związana z
~/.profile
. Jeśli zalogujesz się w środowisku graficznym (to znaczy, jeśli program, w którym wpisujesz hasło, działa w trybie graficznym), nie otrzymasz automatycznie powłoki logowania, która czyta~/.profile
. W zależności od graficznego programu logowania, menedżera okien lub środowiska pulpitu, które uruchamiasz później, oraz od tego, jak twoja dystrybucja skonfigurowała te programy,~/.profile
możesz, ale nie musisz, odczytać. Jeśli tak nie jest, zwykle jest inne miejsce, w którym można zdefiniować zmienne środowiskowe i programy, które mają być uruchamiane po zalogowaniu, ale niestety nie ma standardowej lokalizacji.Zauważ, że możesz zobaczyć tu i tam zalecenia, aby albo umieścić definicje zmiennych środowiskowych,
~/.bashrc
albo zawsze uruchamiać powłoki logowania w terminalach. Oba są złymi pomysłami. Najczęstszym problemem związanym z którymkolwiek z tych pomysłów jest to, że zmienne środowiskowe będą ustawione tylko w programach uruchamianych przez terminal, a nie w programach uruchamianych bezpośrednio za pomocą ikony lub menu lub skrótu klawiaturowego.¹ Dla kompletności, na żądanie: jeśli
.bash_profile
nie istnieje, bash próbuje również.bash_login
przed powrotem do.profile
. Zapomnij, że istnieje.źródło
~/.bash_profile
Zamiast tego można użyć~/.profile
~/.bashrc
instrukcji , ale należy ją również uwzględnić, jeśli powłoka jest interaktywna. wprowadza w błąd, ponieważ są to kwestie ortogonalne. Bez względu na to, czy używasz,~/.bash_profile
czy~/.profile
musisz dołączyć~/.bashrc
do tego, którego używasz, jeśli chcesz, aby stamtąd ustawienia miały wpływ na powłokę logowania.~/.bashrc
ma coś wspólnego z wyborem~/.bash_profile
zamiast tego,~/.profile
co nie jest prawdą. Jeśli ktoś włącza~/.bashrc
dowolny skrypt w czasie logowania (tutaj albo~/.bash_profile
albo~/.profile
), to dlatego, że chce, aby ustawienia~/.bashrc
były stosowane do powłoki logowania w taki sam sposób, jak są one stosowane do powłoki niezalogowanej.Z tego krótkiego artykułu
źródło
W dawnych czasach, gdy pseudo-tty nie były pseudo, a właściwie pisane, a UNIXy były dostępne przez modemy tak wolno, że można było zobaczyć każdą literę drukowaną na ekranie, wydajność była najważniejsza. Aby nieco zwiększyć wydajność, masz pojęcie głównego okna logowania i wszystkich innych okien, w których faktycznie działałeś. W głównym oknie chcesz otrzymywać powiadomienia o każdej nowej poczcie, ewentualnie uruchom inne programy w tle.
Aby to obsłużyć, powłoki pozyskały plik
.profile
specjalnie na „powłoki logowania”. To zrobiłoby specjalne, po skonfigurowaniu sesji. Bash rozszerzył to nieco, aby najpierw spojrzeć na .bash_profile przed .profile, w ten sposób można umieścić tam tylko rzeczy (aby nie spieprzyły powłoki Bourne'a itp., Które również patrzyły na .profile). Inne powłoki, niezalogowane, po prostu źródło pliku rc, .bashrc (lub .kshrc itp.).To jest teraz trochę anachronizm. Nie logujesz się do głównej powłoki tak bardzo, jak logujesz się do menedżera okien GUI. Nie ma innego okna głównego niż inne.
Moja sugestia - nie martw się o tę różnicę, jest ona oparta na starszym stylu korzystania z unixa. Wyeliminuj różnicę w swoich plikach. Cała zawartość pliku .bash_profile powinna wynosić:
[ -f $HOME/.bashrc ] && . $HOME/.bashrc
I umieść wszystko, co naprawdę chcesz ustawić w .bashrc
Pamiętaj, że .bashrc jest pozyskiwany dla wszystkich powłok, interaktywnych i nieinteraktywnych. Możesz zewrzeć źródła dla nieinteraktywnych powłok umieszczając ten kod w górnej części .bashrc:
[[ $- != *i* ]] && return
źródło
.$HOME/.bashrc
jak pokazano powyżej, ustawienia.bashrc
będą dostępne w powłokach logowania, a więc również w środowisku pulpitu. Na przykład w moim systemie Fedoragnome-session
jest uruchamiany tak-$SHELL -c gnome-session
, jak.profile
czytany..bashrc
w.profile
zwykle nie działa, ponieważ.profile
może być wykonywane przez/bin/sh
i nie bash (np. Na Ubuntu dla domyślnego logowania graficznego), a ta powłoka może nie być interaktywna (np. Dla graficznego logowania).[[ $- != *i* ]] && return
”); Podoba mi się, aby niektóre z nich.bashrc
były wykonywane nawet w przypadku powłok nieinteraktywnych, a zwłaszcza w celu ustawienia zmiennych env podczas wydawaniassh hostname {command}
, aby zdalne polecenia były poprawnie wykonywane (nawet jeśli powłoka nie jest interaktywna). Ale inne ustawienia później.bashrc
należy zignorować. Zazwyczaj sprawdzam, czy TERM = głupi i / lub nieuzbrojony, a potem ratuję się wcześnie.Obejrzyj ten znakomity post na blogu autorstwa ShreevatsaR . Oto wyciąg, ale przejdź do postu na blogu, zawiera wyjaśnienie terminów takich jak „powłoka logowania”, schemat blokowy i podobna tabela dla Zsh.
źródło
[ -z "$PS1" ] && return
? Tabela w mojej odpowiedzi podaje listę skryptów uruchamianych przez Basha, niezależnie od zawartości skryptów, jeśli sam skrypt ma linię[ -z "$PS1" ] && return
, to oczywiście by to zadziałało, ale nie sądzę, że powinno to oznaczać, że powinienem zmienić stół.LEPSZY KOMENTARZ DLA GŁOWICY / ETC / PROFILU
Opierając się na powyższej świetnej odpowiedzi Flimma, umieściłem ten nowy komentarz na początku mojego profilu Debian / etc / (może być konieczne dostosowanie go do dystrybucji) .
I ta uwaga na początku każdego innego pliku instalacyjnego, aby się do niego odwołać:
Warto zauważyć, że myślę, że domyślnie źródła / etc / profil Debiana (zawiera) /etc/bash.bashrc (wtedy, gdy istnieje /etc/bash.bashrc). Więc skrypty logowania odczytują oba pliki / etc, podczas gdy non-login czyta tylko bash.bashrc.
Warto również zauważyć, że /etc/bash.bashrc jest ustawiony tak, aby nic nie robić, gdy nie jest uruchamiany interaktywnie. Te dwa pliki są tylko dla interaktywnych skryptów.
źródło
Logika konfiguracji samego basha nie jest szalenie skomplikowana i wyjaśniona w innych odpowiedziach na tej stronie, na temat błędu serwera i wielu blogów. Problemem jest jednak to, co dystrybucje Linuksa tworzą bash , mam na myśli złożoną i różne sposoby domyślnej konfiguracji bash. http://mywiki.wooledge.org/DotFiles krótko wspomina niektóre z tych dziwactw. Oto jeden przykładowy ślad na Fedorze 29, który pokazuje, które źródło plików, które inne pliki i w jakiej kolejności w bardzo prostym scenariuszu: zdalne połączenie z ssh, a następnie uruchomienie innej podpowłoki:
Najbardziej złożona logika Fedory
/etc/bashrc
. Jak widać powyżej,/etc/bashrc
plik bash sam nie wie o tym, że nie bezpośrednio./etc/bashrc
Testy Fedory, czy:... a następnie robi zupełnie różne rzeczy w zależności od nich.
Jeśli uważasz, że możesz zapamiętać powyższy wykres, to szkoda, ponieważ nie jest prawie wystarczający: ten wykres opisuje tylko jeden scenariusz, podczas uruchamiania nieinteraktywnych skryptów lub uruchamiania sesji graficznej dzieją się nieco inne rzeczy. Mam pominięta
~/.profile
. Pominąłembash_completion
skrypty. Ze względu na kompatybilność wsteczną wywołanie bash as/bin/sh
zamiast/bin/bash
zmiany jego zachowania. Co z Zsh i innymi powłokami? I oczywiście różne dystrybucje Linuksa robią to inaczej, na przykład Debian i Ubuntu są dostarczane z niestandardową wersją bas h, mają specyficzne dla Debiana modyfikacje. W szczególności szuka nietypowego pliku:/etc/bash.bashrc
. Nawet jeśli trzymasz się jednej dystrybucji Linuksa, prawdopodobnie ewoluuje ona z czasem. Czekaj: nawet nie dotknęliśmy macOS, FreeBSD, ... Wreszcie, pomyślmy o użytkownikach, którzy utknęli w jeszcze bardziej kreatywnych sposobach, w jakie ich administratorzy skonfigurowali system, z którego muszą korzystać.Jak pokazuje niekończący się strumień dyskusji na ten temat, jest to przegrana sprawa. Tak długo, jak chcesz tylko dodać nowe wartości, niektóre „próby i błędy” wydają się wystarczające. Prawdziwa zabawa zaczyna się, gdy chcesz zmodyfikować w jednym pliku (użytkownika) coś już zdefiniowane w innym (w / etc). Przygotuj się na poświęcenie czasu na opracowanie rozwiązania, które nigdy nie będzie przenośne.
Dla odrobiny zabawy oto „wykres źródłowy” dla tego samego, prostego scenariusza na Clear Linux z czerwca 2019 r .:
źródło