sshクライアントの引数の後に対話型プログラムが続く場合、sshdは疑似端末を使用しないのはなぜですか？

SSHサーバーに接続する通常の方法はssh username@ip_addressです。しかし、ユーザーはリモートマシンでプログラムを実行したいだけかもしれません。したがって、プログラム名は、通常の引数の後に続きますssh username@ip_address <program_name>。たとえば、ssh username@ip_address ls。対話型プログラム（ユーザー入力も受け入れ、出力も提供する）を除いて、その引数は問題ありませんtop。出力は

TERM環境変数が設定されていません。

つまり、sshdとtopプログラムの間に（疑似）端末が接続されていません。解決策は-t、コマンド全体がになる引数を追加することssh -t username@ip_address topです。

私の質問は、なぜデフォルトではsshdも疑似端末を使用して非対話型プログラムと通信できない-tため、対話型プログラムの引数を追加する必要がないのですか？

他の人が言ったように、PTYにはある程度のオーバーヘッドがあることは事実ですが、リモートコマンドの実行時にPTYを使用しない大きな理由は、情報を失うことです。

通常、sshを介してリモートでコマンドを実行すると、コマンドstdoutとstderrストリームはローカルstdoutとに送信されます。つまり、次のように、stderrそれらを個別にリダイレクト/パイプできます。

$ ssh server ls foo bar
ls: cannot access bar: No such file or directory
foo
$ ssh server ls foo bar > stdout 2> stderr
$ cat stdout
foo
$ cat stderr
ls: cannot access bar: No such file or directory

ただし、PTYにstdoutは出力/エラー用の個別のストリームがないため、PTYを使用する場合、すべての出力はに送られます。

$ ssh -t server ls foo bar > stdout 2> stderr
$ cat stdout
ls: cannot access bar: No such file or directory
foo
$ cat stderr
$

sshこれを説明するマニュアルページ：

ユーザーのIDがサーバーに受け入れられると、サーバーは非対話型セッションで特定のコマンドを実行するか、コマンドが指定されていない場合はマシンにログインして、ユーザーに対話型セッションとして通常のシェルを提供します。リモートコマンドまたはシェルとのすべての通信は自動的に暗号化されます。

それは機能であり、おそらくrsh行動の歴史的な理由によって引き起こされます。それはかなり合理的です。ほとんどのコマンドは実際にはインタラクティブではなく、PTYを割り当てるのは自由な操作ではありません（20年前に重要でした）。

ssh呼び出すコマンドがインタラクティブかどうかを判断するにはどうすればよいですか？

この悪夢は、UNIX以外のOSを実行しているマシンにログインしている可能性があることに気づくとさらに悪化します。

簡単な解決策はなく、1つのケースをデフォルトにする必要がありました。