Co robią skrypty w /etc/profile.d?

Czytam o podstawowych skryptach powłoki z wiersza poleceń Linuksa i Biblii skryptów powłoki .

Mówi, że /etc/profileplik ustawia zmienne środowiskowe podczas uruchamiania powłoki Bash. /etc/profile.dKatalog zawiera inne skrypty, które zawierają pliki startowe specyficzne dla aplikacji, które są wykonywane również w momencie uruchamiania przez powłokę.

• Dlaczego te pliki nie są częścią, /etc/profilejeśli są również krytyczne dla uruchamiania Bash?

• Jeśli te pliki są specyficznymi dla aplikacji plikami startowymi, które nie mają krytycznego znaczenia dla uruchamiania Bash, to dlaczego są częścią procesu uruchamiania? Dlaczego nie są uruchamiane tylko wtedy, gdy uruchamiane są określone aplikacje, dla których zawierają ustawienia?

Dlaczego te pliki nie są częścią / etc / profile, jeśli mają również kluczowe znaczenie dla uruchamiania Bash?

Jeśli masz na myśli: „Dlaczego nie są one połączone w jeden gigantyczny skrypt?”, Odpowiedź brzmi:

1. Ponieważ byłby to koszmar konserwacji dla osób odpowiedzialnych za skrypty.
2. Ponieważ ładowanie skryptów jako niezależnych modułów sprawia, że ​​cały system jest bardziej dynamicznie regulowany - poszczególne skrypty można dodawać i usuwać bez wpływu na inne. Itp.
3. Ponieważ są ładowane przez / etc / profile, co czyni je częścią „profilu” bash w ten sam sposób.

Jeśli te pliki są specyficznymi dla aplikacji plikami startowymi, które nie mają krytycznego znaczenia dla uruchamiania Bash, to dlaczego są częścią procesu uruchamiania? Dlaczego nie są uruchamiane tylko wtedy, gdy uruchamiane są określone aplikacje, dla których zawierają ustawienia?

Wydaje mi się, że jest to szersze pytanie dotyczące filozofii projektowania, które podzielę na dwie części. Pierwsze pytanie dotyczy wartości i zasadności korzystania ze środowiska powłoki. Czy ma wartość dodatnią? Tak, jest to przydatne. Czy to najlepsze rozwiązanie wszystkich problemów z konfiguracją? Nie, ale jest bardzo skuteczny do zarządzania prostymi parametrami, a także powszechnie rozpoznawany i rozumiany. Dla kontrastu, powiedzmy, decydując się na heterogeniczną konfigurację takich rzeczy, być może $ PATH może być zarządzane przez oddzielne niezależne narzędzie, preferowane narzędzia, takie jak $ EDITOR, mogą być gdzieś w pliku sqlite, rzeczy $ LC lang mogą znajdować się w pliku tekstowym z plikiem niestandardowy format gdzie indziej itp. - nie tylko używa zmiennych env i/etc/profile.dnagle wydają się prostsze? Prawdopodobnie już wiesz, czym jest zmienna env, jak działają i jak z nich korzystać, w porównaniu do uczenia się 5 zupełnie różnych mechanizmów dla 5 różnych wszechobecnych aspektów tego, co jest odpowiednio nazywane „środowiskiem”.

Drugie pytanie brzmi: „Czy uruchomienie jest na to odpowiedni czas?”, Co nasuwa zarzut, że nie jest bardzo wydajny (wszystkie dane, które mogą, ale nie muszą zostać wykorzystane itp.). Ale:

• Realistycznie rzecz biorąc, nie jest to tak dużo danych, częściowo dlatego, że nikt przy zdrowych zmysłach nie użyłby ich do więcej niż kilku prostych parametrów (ponieważ istnieją inne sposoby konfiguracji aplikacji).
• Jeśli jest używany mądrze, w odniesieniu do rzeczy, które są często wywoływane, ustawienie np. Domyślnej wartości $ CFLAGS z pliku przy każdym wywołaniu gccbyłoby mniej wydajne. Pamiętaj, że ilość zajmowanej pamięci jest ponownie nieskończenie mała.
• Może obejmować rzeczy systemowe, w które może być zaangażowanych więcej niż jedna aplikacja, a powłoka jest wspólną płaszczyzną .

Więcej można dodać do tej listy, ale mam nadzieję, że daje to pewne wyobrażenie o zaletach i wadach tego problemu - głównym „plusie” i głównym „wadzie” jest to, że jest to globalna przestrzeń nazw.

Pliki te są specyficzne dla aplikacji, ale są pozyskiwane podczas uruchamiania powłoki, a nie podczas uruchamiania aplikacji. Używany jest tutaj katalog konfiguracji z tego samego powodu, który znajduje się w wielu innych miejscach. Umożliwia to aplikacji lub pakietowi oprogramowania modyfikowanie konfiguracji. Nie byłoby to możliwe bez podzielonej konfiguracji, ponieważ wiele pakietów próbujących zarządzać / aktualizować pojedynczy plik konfiguracyjny, który może być również modyfikowany przez użytkownika, byłby błędny i bałagan.

Dodatkowa uwaga /etc/profilepochodzi od wszystkich pocisków, a nie tylko od uderzenia. Plik konfiguracyjny specyficzny dla bash jest bashrc i jest pozyskiwany tylko dla interaktywnych powłok.

odpowiedź jordanma jest nieprawidłowa. /etc/profilenie pochodzi od wszystkich muszli. Jak zauważyłeś, nie pochodzi od csh: tcsh- Nie jestem pewien zsh. Pochodzi z shpochodnych Bourne'a ( ), takich jak Korn Shell ( ksh) i BASH ( bash). cshwykorzystuje /etc/login. Ludzie, którzy używają wyłącznie pochodnych Borne Shell, zwykle zapominają o istnieniu innych powłok. Dodają coś, by /etc/profileoczekiwać, że zastosuje się to do „wszystkich użytkowników”, a następnie są zaskoczeni, gdy dziwny użytkownik powłoki C (a my jesteśmy dziwni) nie ma rzeczy, w których skonfigurowali /etc/profile.

Mimo to ludzie zapominają o istnieniu innych powłok pochodnych Borne Shell. Jeśli używają bashlub ksh, mogą dodawać do nich składnię, /etc/profilektóra nie jest poprawna w powłoce Bourne'a, na przykład definiowanie zmiennej i eksportowanie jej w tym samym wierszu. Potem dostajesz skrypt, który działa #!/bin/shi dusi się w składni. /etc/profilepowinien trzymać się składni kompatybilnej z Bourne Shell.

Podobnie, powinieneś trzymać się go samemu .profile(użyj, .bash_profilejeśli chcesz trochę składni bash) - może to być trochę dodatkowe pisanie, ale jest to dodatkowe pisanie, które robisz za jednym razem. Odnośnik, ${HOME}a nie ~itd. Niektóre smaki Uniksa, zadania cron są uruchamiane sh, każda linia Makefilejest przetwarzana sh, więc jeśli pracujesz nad wieloma odmianami UNIX, naprawdę opłaca się utrzymać .profilekompatybilność powłoki Bourne'a. Jako SysAdmin nie mogę powiedzieć, ile razy pomogłem komuś, ustawiając go tak, .profileaby był zgodny z Bourne Shell.

W Linuksie /bin/shjest linkiem do, /bin/basha kiedy go uruchomisz, wygląda na ścieżkę, która została użyta do jego uruchomienia i (teoretycznie) ogranicza się tylko do rzeczy obsługiwanych przez Bourne Shell. Podobnie viw Linuksie tak naprawdę vimznów się ogranicza. Czasami widzisz funkcje „przenikające”. Czasami vimudawanie vi, vimże virobi , robi coś, co nie obsługuje, ponieważ autorzy vimzapomnieli wyłączyć to w trybie „wstecznej kompatybilności”. Nie zdziwiłbym się, gdyby bashudawanie, że shma takie podobne cechy. Nie zdziwiłbym się, gdyby jakaś funkcja „działała na Borne Shell w systemie Linux”, ale nie w systemie UNIX opartym na systemie V lub BSD (AIX, OpenBSD itp.).