Почему удаленный источник 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 .

Remote 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

Которая заканчивается телетайпом (не сетевым подключением), как его видит запущенный 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, но по другой причине.

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

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

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

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

3. Затем среда (например, GNU screen) вызывала дополнительные (не логиновые) оболочки, которые наследовали среду от родительской оболочки входа.

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

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

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

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

Дополнительно

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