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

85

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

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

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

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

asheeshr
источник

Ответы:

71

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

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

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

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

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

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

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

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

лютик золотистый
источник
Does it have positive ... and understood.Что ты здесь пытаешься сказать? Я понял все, кроме этого пункта.
asheeshr
3
Среда оболочки обычно используется для настройки самой оболочки и других вездесущих инструментов. Это не единственный способ, которым можно выполнить настройку, поэтому стоит подумать, является ли среда лучше или хуже, чем другие варианты. Имея «положительную ценность», я имел в виду, что использование среды действительно имеет некоторые преимущества по сравнению с другими вариантами, по крайней мере, WRT «управление простыми параметрами», а именно то, что оно очень эффективно и «широко признано и понято» ... и я Я добавлю немного, чтобы объяснить эту фразу дальше.
Златовласка
Как насчет добавления строк в profile.local? Это приемлемо по сравнению с созданием скриптов в папке profile.d?
Авиндра Гулчаран
@AvindraGoolcharan Различные дистрибутивы могут использовать разные схемы для такого рода вещей. profile.dКаталог работает только потому , что его содержание получены путем /etc/profile, который задается оболочками , такими , как Баш как файл запуска (см Призыва в man bash); если вы редактируете /etc/profile, вы можете отключить /etc/profile.d. /etc/profile.localПохоже, это изобретение SUSE, предположительно откуда-то полученное, /etc/profileчтобы вы могли положить туда свои вещи. Однако, если вы переместите его в систему, отличную от SUSE, и не будете вносить никаких других изменений, он не будет использоваться ничем.
Златовласка
Понятно, это кристально ясно. Да, мы используем SUSE на моей работе. / и т.д. / профиль. кажется намного лучшей ставкой.
Авиндра Гулчаран
13

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

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

jordanm
источник
3
Второй абзац интересный. Поскольку разные оболочки поддерживают разный синтаксис, для этого потребуется существенный общий синтаксис. Верно для bash и sh, но я не думаю, что для других, таких как csh или tcsh, у которых есть свои собственные глобальные сценарии запуска входа в систему. Во многих системах / bin / sh - это просто ссылка на / bin / bash. Но bash изменяет свое поведение, чтобы быть посликс-совместимым при вызове как sh. Поэтому можно подумать, что авторам сценариев в /etc/profile.d нужно быть осторожными, чтобы не использовать расширения bash вне подмножества posix.
Sootsnoot
В Linux есть отдельные файлы .csh и .sh для двух основных типов оболочки.
Суровая
0

ответ Джорданма неверен. /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 и т. Д.).

Дамокл
источник
Вы уверены, что "в Linux /bin/shесть ссылка на /bin/bash"? Это правильное заявление.
41754