Почему я должен `source .profile` в каждом терминале, который я открываю?

Когда мы меняем переменную в ~/.profileUbuntu, мы выполняем команду source .profile. Тогда изменение вступает в силу только в этом терминале. Если мы открываем новый терминал, мы должны выполнить команду source .profileснова. Таким образом, кажется, что разные терминалы имеют свою собственную среду, хотя они могут принадлежать одному и тому же пользователю.

В чем преимущество того, что каждый терминал имеет свой собственный путь среды? Кажется, было бы лучше, если бы разные терминалы, принадлежавшие одному и тому же пользователю, имели одну и ту же переменную среды.

Причина этого в том, что ~/.profileон получен только из логинов. Когда вы открываете новое окно терминала, запускаемая оболочка по умолчанию является оболочкой, не входящей в систему. Если вы выйдете из системы и снова войдете в систему, изменение ~/.profileвступит в силу на всех ваших терминалах, потому что оно ~/.profileпроисходит при входе в сеанс.

Дело не в том, что в разных окнах терминалов разная среда, но получение ресурсов ~/.profileвыполняется только ~/.profileв текущей оболочке (именно это и sourceделает команда).

В отличие от этого, изменение ~/.bashrcнемедленно повлияет на любое новое окно терминала, которое вы открываете, или на любую оболочку Bash, которую вы запускаете, набрав bash, потому что она поставляется всеми интерактивными оболочками Bash.

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

Существует множество случаев, когда процесс устанавливает конкретные переменные среды, чтобы влиять только на процессы, которые он запускает. Например, сценарий может намеренно сбрасывать настройки локали для команд, которые он запускает, так что он может анализировать выходные данные из них. Сценарии сборки для многих больших пакетов программ используют вложенные вызовы makeэтих координат друг с другом через переменные среды. Специализированным инструментам может потребоваться изменить условия работы других программ, которые они запускают, выполняя трюки с $ LD_PRELOAD или $ PATH.

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

Другие переменные среды содержат информацию о конкретном сеансе, в котором запущен процесс. Программы ожидают, что $ TERM описывает набор команд конкретного терминала (или эмулятора терминала), к которому они подключены; выполнение общих настроек для каждого пользователя сделает невозможным вход в одну и ту же систему с несколькими различными типами терминалов. Даже если у вас есть только одна часть терминального оборудования и вы никогда не входите удаленно, такие программы, как, например, screenзависят от установки другого $ TERM для процессов, которые выполняются внутри их сеанса.

Лучше было бы задать вопрос: почему мы используем механизм связи процесс-подпроцесс для настройки предпочтений пользователя, а не базу данных для каждого пользователя?

Ответ: Потому что он работает достаточно хорошо , и выгоды от создания базы данных для каждого пользователя не достаточно большой , что работа меняется все , чтобы использовать , что вместо переменных окружения будет сделано.

(Я могу думать очень мало настроек предпочтений там , где не было бы некоторые случаи использования , где это удобно , чтобы изменить их только для выполнения одного сценария, например. Так что , чтобы не потерять функциональность, все еще необходимо будет переопределение путем переменные среды, что приводит к дополнительной сложности и более запутанным пользователям).

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