Что делают скрипты в /etc/profile.d?

Я читаю об основных сценариях оболочки из командной строки Linux и Библии сценариев оболочки .

В нем говорится, что /etc/profileфайл устанавливает переменные окружения при запуске оболочки Bash. В этом /etc/profile.dкаталоге содержатся другие сценарии, содержащие файлы запуска для конкретного приложения, которые также выполняются оболочкой во время запуска.

• Почему эти файлы не являются частью, /etc/profileесли они также важны для запуска Bash?

• Если эти файлы являются файлами запуска приложения, не критичными для запуска Bash, то почему они являются частью процесса запуска? Почему они не запускаются только при выполнении определенных приложений, для которых они содержат настройки?

Почему эти файлы не являются частью / etc / profile, если они также важны для запуска Bash?

Если вы имеете в виду «Почему они не просто объединены в один гигантский сценарий?», Ответ:

1. Потому что это был бы кошмар для тех, кто отвечает за сценарии.
2. Поскольку загрузка сценариев в качестве независимых модулей делает всю систему более динамически настраиваемой - отдельные сценарии можно добавлять и удалять, не затрагивая другие. И т.п.
3. Потому что они загружаются через / etc / profile, что в любом случае делает их частью "профиля" bash.

Если эти файлы являются файлами запуска приложения, не критичными для запуска Bash, то почему они являются частью процесса запуска? Почему они не запускаются только при выполнении определенных приложений, для которых они содержат настройки?

Это кажется мне более широким вопросом философии дизайна, который я разделю на две части. Первый вопрос касается ценности и целесообразности использования среды оболочки. Это имеет положительное значение? Да, это полезно. Это лучшее решение для всех проблем конфигурации? Нет, но он очень эффективен для управления простыми параметрами, а также широко признан и понят. В отличие от этого, если принять решение о гетерогенной настройке таких вещей, возможно, $ PATH может управляться отдельным независимым инструментом, предпочтительные инструменты, такие как $ EDITOR, могут находиться где-то в файле sqlite, а материал $ LC lang может быть в текстовом файле с пользовательский формат где-то еще и т. д. - не только с помощью переменных env и/etc/profile.dвдруг показаться проще? Вы, наверное, уже знаете, что такое переменная env, как они работают и как их использовать, в отличие от изучения 5 совершенно разных механизмов для 5 различных вездесущих аспектов того, что соответствующим образом называется «средой».

Второй вопрос: «Является ли время запуска подходящим для этого?», В связи с чем возникает возражение, что он не очень эффективен (все эти данные, которые могут или не могут быть использованы, и т. Д.). Но:

• Реально, это не так уж много данных, отчасти потому, что никто в здравом уме не будет использовать их для более чем нескольких простых параметров (поскольку существуют другие способы настройки приложения).
• Если он используется разумно, в отношении вещей, которые обычно вызываются, то установка, например, $ CFLAGS по умолчанию из файла где-нибудь при каждом вызове gcc, будет менее эффективной. Имейте в виду, что количество задействованной памяти, опять же, бесконечно мало.
• Он может включать системные вещи, с которыми может быть связано более одного приложения, и оболочка является общей почвой .

К этому списку можно добавить больше, но, надеюсь, это даст вам некоторое представление о плюсах и минусах проблемы - основные «за» и «против» в том, что это глобальное пространство имен.

Эти файлы относятся к конкретному приложению, но создаются при запуске оболочки, а не при запуске приложения. Каталог конфигурации используется здесь по той же причине, что и во многих других местах. Это позволяет приложению или программному пакету изменять конфигурации. Это было бы невозможно без раздельной конфигурации, так как несколько пакетов, пытающихся управлять / обновить один файл конфигурации, который также может быть изменен пользователем, были бы глючными и грязными.

Также примечание, /etc/profileпоставляемое всеми оболочками, а не только bash. Конфигурационный файл bash - это bashrc, он поставляется только для интерактивных оболочек.

ответ Джорданма неверен. /etc/profileпоставляется не всеми оболочками. Как вы указываете, это не источником csh, tcsh- я не уверен в этом zsh. Он поставляется производными Bourne shell ( sh), такими как 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если вам нужен некоторый синтаксис bash) - это может быть немного дополнительная печать, но это дополнительная печать, которую вы делаете все один раз. Ссылка, ${HOME}а не ~и т. Д. Некоторые версии Unix, cron-задания выполняются sh, каждая ваша строка Makefileобрабатывается sh, поэтому, если вы работаете с несколькими версиями UNIX, то стоит поддерживать .profileсовместимость оболочки Bourne. Как системный администратор, я не могу сказать вам, сколько раз я помогал кому-то, настраивая его .profileна совместимость с Bourne Shell.

В Linux /bin/shэто ссылка на /bin/bashнее, и когда вы ее запускаете, она выглядит как путь, который использовался для ее запуска, и (теоретически) ограничивается только тем, что поддерживает Bourne Shell. Аналогично, viв Linux действительно vim, опять же, ограничивает себя. Изредка вы видите особенности «прокачки». Время от времени vimпритворяется, что viделает что-то, vimчто viне поддерживает, потому что авторы vimзабыли отключить это в режиме «обратной совместимости vi». Я не удивлюсь, если у bashпритворства будут shкакие-то схожие черты. Не удивлюсь, если какая-то функция «работает в Borne Shell в Linux», но не в UNIX на базе System V или BSD (AIX, OpenBSD и т. Д.).