リモートBashが.bashrcではなく.bash_profileをソースするのはなぜですか

Bashマニュアルによると：

Bashは、リモートシェルデーモン（通常はrshdまたはセキュアシェルデーモンsshd）によって実行されるときのように、ネットワーク接続に接続された標準入力で実行されているかどうかを判断しようとします。この方法で実行されているとBashが判断した場合、Bashは〜/ .bashrcからコマンドを読み取り、実行します（そのファイルが存在し、読み取り可能な場合）。

このBashのソース~/.bashrc：

ssh user@host :

しかし、このBashのソース~/.bash_profile：

ssh user@host

仕様によると、これら2つのコマンドに違いはありません。どちらの場合も、stdinはネットワーク接続に接続されていませんか？

ログインシェルは最初に読み取り/etc/profile、次に~/.bash_profile。

非ログインシェルは/etc/bash.bashrc、から読み取り、それからを読み取ります~/.bashrc。

なぜそれが重要なのですか？

次の行のためman ssh：

コマンドが指定されている場合、ログインシェルの代わりにリモートホストで実行されます。

言い換えると、sshコマンドにオプションのみ（コマンドではない）がある場合、次のようになります。

ssh user@host

ログインシェルが起動し、ログインシェルはを読み取ります~/.bash_profile。

持っていないのsshコマンドのコマンドを、のように：

ssh user@host :

コマンドがある場所:（または何もしない）。
それはなりませんので、ログインシェルを起動~/.bashrc読まされるものです。

リモート標準

リモートコンピュータの/ dev / stdinに提供されているtty接続は、実際の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がそれを見ると、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を読み取りますが、理由は異なります。

あなたは「なぜ」ではなく「なぜ」について尋ねるので、その観点から答えようとします。以下は、過去に物事が起こった理由が今日のようになった理由のかなりの根拠になります。

2つの異なるスタートアップファイル（「プロファイル」と「rc」）を持つ理由は、これまでマシンで作業する一般的な方法が次のとおりだったためです。

1. 何らかの種類の実際の端末または他のワークステーションからログインし、ログインシェルを取得します。このシェルは、ユーザーの環境を呼び出し/etc/profileて~/.profileセットアップします。

2. ユーザーが入力したい環境を呼び出します。この環境はXorgでもかまいませんが、ほとんどの場合、GNU screenなどのマルチプレクサーです。

3. 環境（GNU画面など）は、親ログインシェルから環境を継承する追加の（非ログイン）シェルを呼び出します。

これは、開発中cshおよびbash開発中にUNIXマシンにログインする一般的な方法でした。したがって、とにかく環境を継承しているシェルで再度読むのは無駄だと思われまし~/.profileた。

bash次に~/.bashrc、これらの非ログインシェルの追加設定用に追加されました。 csh（およびtcsh）非ログインシェル用の「rc」ファイルを追加しませんでした。csh/ tcshは、POSIXの一部であるbourneシェルと互換性のあるシェルではないことに注意してくださいbash。別のbourne互換シェルでkshは、環境変数（と呼ばれるENV）が追加されました。これは、定義されていれば、非ログイン用の実行コマンド（「rc」）ファイルとして使用されますksh。

そのため、新しいバージョンのbourneシェルでは、GNU画面（または類似の）によって多重化されたシェル内に存在するが、最初に入力したときに表示されるシェルには存在しないエイリアスやその他のクイックオプションの利便性として、追加の構成ファイルが追加されました機械。

グラフィカルディスプレイマネージャ（GDM）の登場により、GDMには独自の初期化ファイル（~/.xinitおよび~/.xsession）があるため、「プロファイル」ファイルと「rc」ファイルの区別は無意味になりました。次に、GDMの内部から記述されたシェルは、ユーザーの気まぐれに応じてログインシェルまたは非ログインシェルになる可能性があり、非ログインシェルが常にログインシェルである親を持つケースは、もは​​や真実ではありません。

追加

シェルスタートアップファイルの比較に関する私のお気に入りの表の 1つは、bourneシェルと互換性のあるシェルがprofileファイルを使用するのに対し、他のシェルは使用しない方法を示しています。これは、以前は初期シェル（マルチプレクサを起動したシェル）がBourne互換シェルである必要があったためです。