Что делает сценарии в/etc/profile.d делают?
Здесь существует две проблемы.
Прежде всего, оба Ваших правила udev не достаточно точны. Да, они могут инициировать действия с включением/отключением карты флэш-памяти с интерфейсом USB, но они могли бы также быть инициированы, когда Ваши жесткие диски распознаны при начальной загрузке.
Вторая проблема может быть более серьезной в последствиях: необходимо всегда размонтировать диски прежде, чем отключить их. Иначе и диск и Ваша система могут пострадать. Я лично видел, что люди уничтожают свои флеш-накопители этот путь.
Почему эти файлы не являются частью/etc/profile, если они также очень важны для запуска Bash?
Если Вы имеете в виду, "Почему они только не объединены в один гигантский сценарий?", ответ:
- Поскольку это было бы кошмаром обслуживания для людей, которые ответственны за сценарии.
- Поскольку загрузка сценариев как независимые модули делает целую систему более динамично корректируемой - отдельные сценарии могут быть добавлены и удалены, не влияя на другие. И т.д.
- Поскольку они загружаются через/etc/profile, который делает их частью удара "профиль" таким же образом так или иначе.
Если эти файлы являются специализированными файлами запуска, не очень важными для запуска Bash, то, почему они, отделяются процесса запуска? Почему они не выполняются только, когда определенные приложения, для которых они содержат настройки, выполняются?
Это кажется мне как более широкий вопрос о принципах проектирования, что я разделю на два. Первый вопрос о значении и уместности использования среды оболочки. Это имеет положительное значение? Да, это полезно. Действительно ли это - лучшее решение всех проблем конфигурации? Нет, но это очень эффективно для управления простыми параметрами, и также широко распознанный и понятый. Контраст, что для высказывания, решая настроить такие вещи разнородно, возможно, $PATH могли управлять отдельный независимый инструмент, предпочтительные инструменты, такие как $EDITOR, мог быть в sqlite файле где-нибудь, $LC, которым материал Ленга мог быть в текстовом файле с пользовательским форматом где-то в другом месте, и т.д. - не делает просто использующих огибающих переменных и /etc/profile.d внезапно кажетесь более простыми? Вы, вероятно, уже знаете, какова огибающая переменная, как они работают и как использовать их, по сравнению с изучением 5 совершенно других механизмов для 5 различных повсеместных аспектов того, что соответственно называют "средой".
Второй вопрос, "Действительно ли запуск является подходящим временем для этого?", который просит возражения, что это не очень эффективно (все эти данные, которые могут или не могут привыкнуть, и т.д.). Но:
- Реалистично, это не все так много данных, частично потому что никто в их правильном уме не использовал бы его для больше, чем нескольких простых параметров (так как существуют другие средства конфигурирования приложения).
- Если это используется мудро относительно вещей, которые обычно вызываются, то, устанавливая, например, $CFLAGS по умолчанию из файла где-нибудь каждый раз Вы вызываете
gccбыло бы менее эффективным. Следует иметь в виду, что включенный объем памяти является, снова, бесконечно малой величиной. - Это может включить системные вещи, с которыми может быть связано больше чем одно приложение, и оболочка является общим заземлением.
Больше могло быть добавлено к тому списку, но надо надеяться это дает Вам некоторое представление о за и против проблемы - 'про' майор и главный 'довод "против"', являющийся этим, это - глобальное пространство имен.
Те файлы характерны для приложения, но получены при запуске оболочки, не, когда приложение запускается. Каталог конфигурации используется здесь по той же причине, что это найдено во многих других местах. Это позволяет пакету приложений или пакету программного обеспечения изменять конфигурации. Это не было бы возможно без конфигурации разделения как несколько пакетов, пытающихся управлять/обновлять единственным конфигурационным файлом, который может также быть изменен пользователем, был бы багги и грязный.
Также примечание стороны, /etc/profile получен всеми оболочками, не просто колотят. Удар определенный конфигурационный файл является bashrc и только полученный для интерактивных оболочек.
-
1Второй абзац интересен. Так как различные оболочки поддерживают другой синтаксис, это потребовало бы, чтобы был значительный общий синтаксис. Верный для удара и sh, но я не думаю так для других как csh или tcsh, которые имеют их собственные глобальные сценарии запуска входа в систему. Во многих системах/bin/sh является просто ссылкой на/bin/bash. Но удар изменяет свое поведение, чтобы быть posix-совместимым при вызове как sh. Таким образом, можно было бы думать, что авторы сценариев в/etc/profile.d должны будут стараться избегать использования расширений удара вне posix подмножества. – sootsnoot 10.10.2014, 09:28
-
2В соответствии с Linux существует отдельный .csh и .sh файлы для двух главных типов оболочки. – stark 13.01.2015, 16:25
ответ Джорданма неверен. /etc/profileне является источником всех оболочек. Как вы указываете, это не источник csh, tcsh-. Я не уверен насчет zsh. Его источником являются производные оболочки Bourne (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, действительно стоит поддерживать совместимость с оболочкой .profileBourne. Как системный администратор, я не могу сказать вам, сколько раз я помогал кому-то, исправляя их .profileдля совместимости с Bourne Shell.
В Linux /bin/shявляется ссылкой на /bin/bash, и когда вы запускаете его, он выглядит как путь, который использовался для его запуска, и (теоретически )ограничивается только тем, что Bourne Шелл поддерживает. Точно так же viв Linux на самом деле vim, опять же самоограничение. Иногда вы видите, что функции «просачиваются». Иногда vim, выдавая себя за vi, делает что-то, что vimподдерживает, а viнет, потому что авторы vimзабыли отключить это в режиме "обратной совместимости vi". Я не удивлюсь, если у bash, притворяющегося sh, есть некоторые похожие черты «просачивания». Не удивлюсь, если какая-то функция «работает в Borne Shell в Linux», но не в UNIX на основе System V или BSD (, AIX, OpenBSD и т. д. ).
Does it have positive ... and understood.Что Вы пытаетесь сказать здесь? Я понял все кроме того абзаца. – asheeshr 09.02.2013, 16:22profile.dкаталог только работает, потому что его содержание получено/etc/profile, который указан оболочками, такими как удар как файл запуска (см. ВЫЗОВ вman bash); если Вы редактируете/etc/profile, можно отключить/etc/profile.d./etc/profile.localкажется, изобретение SUSE, по-видимому, полученное от где-нибудь такого как/etc/profileтак, чтобы можно было поместить собственный материал там. Однако, если Вы переместите его в не систему SUSE и не внесете никакие другие корректировки, то это не будет использоваться ничем. – goldilocks 30.07.2014, 22:09