Чому віддалене джерело Bash .bash_profile замість .bashrc

Посібник Баша говорить:

Bash намагається визначити, коли він працює за допомогою його стандартного входу, підключеного до мережевого з'єднання, як коли виконується віддаленим демоном оболонки, як правило, rshd, або захищеним демоном захищеної оболонки sshd. Якщо Bash визначає, що його виконують таким чином, він зчитує та виконує команди з ~ / .bashrc, якщо цей файл існує та читається.

Це джерела Баша ~/.bashrc:

ssh user@host :

Але це джерела Баша ~/.bash_profile:

ssh user@host

Я не бачу різниці в цих двох командах відповідно до специфікації. Чи stdin не підключений до мережевого з'єднання в обох випадках?

Спершу зчитується оболонка для входу, /etc/profileа потім ~/.bash_profile.

Оболонка без входу в систему зчитується з /etc/bash.bashrcцього моменту ~/.bashrc.

Чому це важливо?

Через цей рядок у man ssh:

Якщо вказана команда , вона виконується на віддаленому хості замість оболонки входу.

Іншими словами, якщо команда ssh має лише параметри (а не команду), наприклад:

ssh user@host

Він запустить оболонку входу, оболонка входу зчитується ~/.bash_profile.

Команда ssh, яка має таку команду , як:

ssh user@host :

Де команда :(або нічого не робити).
Він не запустить оболонку входу, тому ~/.bashrcте, що буде прочитано.

Віддалений стдин

Підключення 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 (не мережевим підключенням), як бачить запущений баш.

Для з'єднання 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) буде викликати додаткові оболонки (не вхід у систему), які успадковують середовище від батьківської оболонки входу.

Це був загальний спосіб увійти до машини UNIX за час, коли cshі bashрозроблявся. Тому вважалося марним ~/.profileзнову читати в оболонках, які все-таки успадковували навколишнє середовище.

bashпотім додається ~/.bashrcдля додаткової конфігурації для цих оболонок без входу. csh(і tcsh) ніколи не додавали жодного файлу "rc" для оболонок без входу. Зауважте, що csh/ tcshне є оболонками, сумісними з оболонкою Bourne (яка є частиною POSIX), поки bashє. Інша оболонка, сумісна з bourne ksh, додала змінну середовища (називається ENV), яка, якщо вона буде визначена, буде використовуватися як файл запуску команд ("rc") для невходу в систему ksh.

Так, так, новіші версії оболонок Bourne додали додатковий файл конфігурації як зручність для псевдонімів та інших швидких опцій, які будуть наявні всередині оболонок, змішаних на екрані GNU (або подібних), але відсутні в оболонці, яку ви отримуєте при першому введенні в верстат.

З підвищенням диспетчерів графічних дисплеїв (GDM) диференціація між "профільними" файлами та "rc" файлами стала безглуздою, оскільки GDM матиме власні файли ініціалізації (наприклад, ~/.xinitта ~/.xsession). Тоді оболонки, заявлені зсередини GDM, можуть бути оболонками для входу або не входами в систему, залежно від примх користувачів, і випадок, коли оболонка без входу завжди матиме батьків, що є оболонкою для входу, вже не відповідає дійсності.

Додатково

Одна з моїх улюблених таблиць щодо порівняння файлів запуску оболонки показує, як сумісні оболонки Bourne використовують profileфайли, а інші оболонки - не. Це тому, що в минулому початкова оболонка (та, яка запустила мюксер) мала бути оболонкою, сумісною з bourne.