Що роблять сценарії в /etc/profile.d?

Я читаю про базові сценарії оболонки з командного рядка Linux та Біблії Shell Scripting .

Це говорить про те, що /etc/profileфайл встановлює змінні середовища при запуску оболонки Bash. У /etc/profile.dкаталозі містяться інші сценарії, що містять файли запуску, орієнтовані на додаток, які також виконуються під час запуску оболонкою.

• Чому ці файли не є частиною, /etc/profileякщо вони також є критичними для запуску Bash?

• Якщо ці файли - це файли запуску, орієнтовані на додаток, не важливі для запуску Bash, то чому вони є частиною процесу запуску? Чому вони не запускаються лише тоді, коли виконуються конкретні програми, для яких вони містять налаштування?

Чому ці файли не є частиною / etc / profile, якщо вони також є критичними для запуску Bash?

Якщо ви маєте на увазі "Чому вони не просто поєднуються в один гігантський сценарій?", Відповідь така:

1. Тому що це був би кошмар на підтримку людей, які відповідають за сценарії.
2. Оскільки завантаження скриптів як незалежних модулів робить всю систему більш динамічно регульованою - окремі сценарії можна додавати та видаляти, не впливаючи на інші. І т.д.
3. Тому що вони завантажуються через / etc / profile, що робить їх частиною bash "профілю" так само інакше.

Якщо ці файли - це файли запуску, орієнтовані на додаток, не важливі для запуску Bash, то чому вони є частиною процесу запуску? Чому вони не запускаються лише тоді, коли виконуються конкретні програми, для яких вони містять налаштування?

Мені це здається більш широким питанням філософії дизайну, яке я розділю на два. Перше питання - про значення та доцільність використання середовища оболонки. Чи має воно позитивне значення? Так, це корисно. Це найкраще рішення всіх проблем із конфігурацією? Ні, але він дуже ефективний для управління простими параметрами, а також широко визнаний і зрозумілий. На противагу цьому, вирішуючи конфігурувати такі речі неоднорідно, можливо, $ PATH може управлятись окремим незалежним інструментом, переважні інструменти, такі як $ EDITOR, можуть бути десь у файлі sqlite, $ $ lang речі можуть бути у текстовому файлі з спеціальний формат деінде тощо - не використовує лише env змінні та/etc/profile.dраптом здається простішим? Напевно, ви вже знаєте, що таке змінна env, як вони працюють і як їх використовувати, порівняно з вивченням 5 абсолютно різних механізмів для 5 різних всюдисущих аспектів того, що належним чином називається "навколишнє середовище".

Друге питання: "Чи запуск відповідний час для цього?", Яке напрошується заперечення, що це не дуже ефективно (усі ті дані, які можуть або не можуть бути використані тощо). Але:

• Реально, це не все так багато даних, частково тому, що ніхто з розуму не використовує їх для декількох простих параметрів (оскільки існують інші засоби налаштування програми).
• Якщо воно використовується розумно, що стосується речей, до яких зазвичай звертаються, то встановлення, наприклад, $ CFLAGS за замовчуванням з файлу десь кожного разу, коли ви викликаєте, gccбуло б менш ефективним. Майте на увазі, що об'єм пам'яті, що займається, знову ж таки нескінченно малий.
• Він може включати системні речі, з якими може бути задіяно більше однієї програми, а оболонка є спільним принципом .

До цього списку можна додати більше, але, сподіваємось, це дає вам деяке уявлення про плюси і мінуси проблеми - головний "про" і головний "кон", що це глобальний простір імен.

Ці файли є специфічними для програми, але вони отримуються при запуску оболонки, а не при запуску програми. Тут використовується конфігураційний каталог з тієї ж причини, що і в багатьох інших місцях. Це дозволяє додатку чи програмному пакету змінювати конфігурації. Це було б неможливо без розділеної конфігурації, оскільки кілька пакетів, які намагаються керувати / оновлювати єдиний файл конфігурації, який також може бути змінений користувачем, були б баггі та брудними.

Також бічна нота, яку /etc/profileподають усі снаряди, а не лише удар. Файл конфігурації для bash - це bashrc і призначений лише для інтерактивних оболонок.

Відповідь Йордана невірна. /etc/profileвиводиться не всіми оболонками. Як ви зазначаєте, це не є джерелом csh, tcsh- я не впевнений у цьому zsh. Він походить від shпохідних Bourne shell ( ), таких як Korn Shell ( ksh) та BASH ( bash). cshвикористовує /etc/login. Люди, які схильні використовувати виключно похідні Borne Shell, як правило, забувають про існування інших оболонок. Вони додають щось, /etc/profileочікуючи, що це застосується до "всіх користувачів", а потім дивується, коли у непарного користувача C Shell (а у нас це дивна партія) немає речей, які вони налаштовували /etc/profile.

Незважаючи на це, люди, як правило, забувають про інші похідні оболонки Borne Shell. Якщо вони використовують bashабо ksh, вони не соромляться додавати синтаксис до того, /etc/profileщо не відповідає дійсності в Bourne Shell, наприклад скажімо, визначаючи змінну та експортуючи її в той самий рядок. Потім ви отримуєте якийсь сценарій, який це робить, #!/bin/shі він задавлюється синтаксисом. /etc/profileмає дотримуватися сумісного синтаксису Bourne Shell.

Так само вам слід дотримуватися його самостійно .profile(використовуйте, .bash_profileякщо ви хочете трохи синтаксису баш) - це може бути трохи зайвим введенням тексту, але це додаткове введення, яке ви робите все один раз. Довідково, ${HOME}а не ~і т. Д. Деякі аромати Unix, задачі на роботі з хроном, обробляються під shкожним вашим рядком Makefile, обробляється sh, тому якщо ви працюєте в декількох ароматах UNIX, це дійсно платить за те, щоб зберегти .profileсумісність оболонки Bourne. Як SysAdmin, я не можу сказати вам, скільки разів я допомагав комусь, налаштовуючи їх .profileна сумісність Борна Шелла.

В Linux /bin/sh- це посилання на те, /bin/bashі коли ви запускаєте його, він виглядає шляхом, який використовувався для його запуску, і (теоретично) обмежується лише речами, які підтримує Bourne Shell. Так само і viв Linux справді vim, знову обмежує себе. Іноді ви бачите функції, які "кровоточать". Іноді vimприкидаючись vi, що зробить щось, що vimпідтримує viце не тому, що автори vimзабули відключити це в режимі "vi назад" сумісності ". Я не був би здивований, якби bashприкидався, що shмає якісь подібні функції "кровоточити". Не здивуєшся, якщо якась функція "працює на Borne Shell в Linux", але не на UNIX (AIX, OpenBSD тощо) на базі System V або BSD.