Почему удаленный Bash использует .bash_profile вместо .bashrc

В руководстве Bash говорится:

Bash пытается определить, когда он запускается со стандартным входом, подключенным к сетевому соединению, как при выполнении удаленным демонами оболочки, обычно rshd, или с помощью sshd защищенной оболочки. Если Bash определяет, что он выполняется таким образом, он считывает и выполняет команды из ~ / .bashrc, если этот файл существует и доступен для чтения.

  • Как передать хеш md5 в оболочку
  • Направление на массив Bash
  • Возможно выполнить команду pipe с помощью su через ssh
  • вывод в файл, затем использовать файл для ввода
  • Как вызвать ошибку с помощью команды Trap
  • Где должен быть файл authorized_keys, если я хочу ssh на «localhost»?
  • Эти источники Bash ~/.bashrc :

     ssh user@host : 

    Но эти источники Bash ~/.bash_profile :

     ssh user@host 

    Я не вижу разницы в этих двух командах в соответствии со спецификацией. Не подключен ли stdin к сетевому соединению в обоих случаях?

  • Как настроить ssh-сервер для mac с пользовательским ip из github?
  • отправить ctrl + q в процесс в bash
  • bash getopts, только короткие варианты, все требуют значений, собственной проверки
  • Безопасно ли удалить файл сценария из этого скрипта?
  • Какие новые функции доступны для bash 4?
  • Как остановить фоновый процесс, запущенный в том же скрипте, без выхода из сценария?
  • 2 Solutions collect form web for “Почему удаленный Bash использует .bash_profile вместо .bashrc”

    Сначала оболочка для входа в систему считывает /etc/profile а затем ~/.bash_profile .

    Оболочка без входа читает /etc/bash.bashrc а затем ~/.bashrc .

    Почему это важно?

    Из-за этой строки в man ssh :

    Если задана команда , она выполняется на удаленном хосте вместо оболочки входа.

    Другими словами, если команда ssh имеет только параметры (а не команду), например:

     ssh user@host 

    Он запустит оболочку для входа, оболочка для входа читает ~/.bash_profile .

    Команда ssh, которая имеет команду , например:

     ssh user@host : 

    Где команда : (или ничего не делать).
    Он не запустит оболочку входа, поэтому ~/.bashrc – это то, что будет прочитано.


    Удаленный stdin

    Поставляемое соединение tty для / dev / stdin на удаленном компьютере может быть фактическим tty или чем-то еще.

    Для:

     $ ssh sorontar@localhost /etc/profile sourced $ ls -la /dev/stdin lrwxrwxrwx 1 root root 15 Dec 24 03:35 /dev/stdin -> /proc/self/fd/0 $ ls -la /proc/self/fd/0 lrwx------ 1 sorontar sorontar 64 Dec 24 19:34 /proc/self/fd/0 -> /dev/pts/3 $ ls -la /dev/pts/3 crw--w---- 1 sorontar tty 136, 3 Dec 24 19:35 /dev/pts/3 

    Который заканчивается в TTY (а не в сетевом соединении), так как это началось bash.

    Для подключения ssh с помощью команды:

     $ ssh sorontar@localhost 'ls -la /dev/stdin' sorontar@localhost's password: lrwxrwxrwx 1 root root 15 Dec 24 03:35 /dev/stdin -> /proc/self/fd/0 

    Список TTY начинается так же, но обратите внимание, что / etc / profile не был получен.

     $ ssh sorontar@localhost 'ls -la /proc/self/fd/0' sorontar@localhost's password: lr-x------ 1 sorontar sorontar 64 Dec 24 19:39 /proc/self/fd/0 -> pipe:[6579259] 

    Что сообщает оболочке, что соединение является каналом (а не сетевым соединением).

    Таким образом, в обоих тестовых случаях оболочка не может знать, что соединение связано с сетью и поэтому не читает ~/.bashrc (если мы говорим только о подключении к сети). Он читает ~ / .bashrc, но по другой причине.

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


    Причина наличия двух разных файлов автозагрузки («профиль» и «rc») заключается в том, что в прошлом обычным способом работы на машине было:

    1. Войдите с какого-либо реального терминала или другой рабочей станции и получите оболочку входа . Эта оболочка будет вызывать /etc/profile и ~/.profile и настраивать среду для пользователя.

    2. Вызовите среду, которую пользователь хочет ввести. Эта среда может быть Xorg, но в большинстве случаев это был мультиплексор, такой как экран GNU.

    3. Окружающая среда (например, экран GNU) будет вызывать дополнительные (не-login) оболочки, которые наследуют среду от родительской оболочки входа.

    Это был обычный способ входа в систему UNIX во время разработки csh и bash . Поэтому было сочтено расточительным читать ~/.profile снова в оболочках, которые наследуют среду в любом случае.

    bash затем добавила ~/.bashrc для дополнительной настройки для этих недействительных оболочек. cshtcsh ) никогда не добавлял никаких «rc» файлов для не-login-оболочек. Обратите внимание, что csh / tcsh не являются оболочками, совместимыми с оболочкой bourne (которая является частью POSIX), в то время как bash . Другая совместимая с bourne оболочка, ksh , добавила переменную окружения (называемую ENV ), которая, если была определена, будет использоваться в качестве файла команды запуска («rc») для не-входа ksh .

    Итак, более новые версии оболочек bourne добавили дополнительный файл конфигурации в качестве удобства для псевдонимов и других быстрых опций, которые будут присутствовать внутри оболочек, смешанных с экраном GNU (или аналогичных), но не присутствующих в оболочке, которую вы получаете, когда вы впервые вводите машина.

    С повышением графических менеджеров дисплея (GDM) дифференциация между файлами профиля и файлами «rc» стала бессмысленной, поскольку у GDM были свои собственные файлы инициализации (например, ~/.xinit и ~/.xsession ). Тогда оболочки, заявленные изнутри GDM, могут быть входом в систему входа или без входа в систему в зависимости от прихотей пользователя, а случай, когда оболочка не-login всегда будет иметь родительский элемент, который является оболочкой входа, больше не верен.

    дополнительный

    Одна из моих любимых таблиц о сравнении файлов с загрузкой оболочки показывает, как оболочки оболочки, совместимые с bourne, используют файлы profile то время как другие оболочки не работают. Это связано с тем, что в прошлом исходная оболочка (та, которая запускала мультиплексор) должна была быть совместимой с bourne оболочкой.

    Linux и Unix - лучшая ОС в мире.