scp(1) を使用してあるホストから別のホストにファイルをコピーする実行中のシステムがあります。システムは一連のファイルを処理していますが、そのうちの1つで停止しました。つまり、昨日はscpコマンドを起動しましたが、今日でも実行され続けています。
strace を実行すると、scp が ssh サブプロセスの stdout に関連付けられたパイプファイルの読み取りを待っていることがわかります。つまり、このサブプロセスはfd 4の読み取りを待っています/dev/tty。
known_hostsSSH 宛先のホストキーがソースホストのホストキーと競合します。長い間実行されているSCPの起動に触れました。これでknown_hostsすべてが設定されているため、メッセージを表示せずにソースからすべての宛先にSSHを接続できます。
私の前提は、ssh小さなタイミングウィンドウが発生し、ユーザーに不明なホストキーが表示され、確認（"yes\n"）が続くのを待っていることです。
ユーザーが入力したようにread呼び出しが機能するようにする方法はありますか（もしそうなら、どうすれば）？sshyes
echo foobar > /dev/tty私がxterm（別のコンピュータ）にいるときにfoobar私のコンソールに書き込みます。当然、echo foobar > /proc/<pid>/fd/4Iがへのシンボリックリンクであっても同じ結果が発生します/dev/tty。それでは、sshにどのように入力を受けますか？
私の仮説をテストしたり、別の方法で動作させる方法を知っている人がいる場合は、sshその話も聞きたいです。
ベストアンサー1
作成時にプロセスIDを考慮しないでください/dev/tty。これで成功することはできません。
同じですが装備、プロセスは特定のデバイスで別のファイル記述子を開きます。 Linuxの場合、プロセスID（/ proc /）がわかっている場合は、個々のファイル記述子を操作できます。PID/ fd / 0は、IDを持つプロセスの標準入力です。PID。
あなたの場合、プログラムはデバイスを開き、そのファイル記述子は/ proc /にもあります。PID/fd（ただしわからない）。アプリケーションは、このディレクトリにあるシンボリックリンク情報を「表示」して機能します。
詳しくは、/proc/の項目はPID/ fdはすべて異なるinode値を持ちます（ファイル記述子が異なるため）。 proc/の項目をエコーします。PID/ fdはファイル記述子をエコーするという意味です。
しかし、sshはその方向の入力を期待せず、補足的なヒントを提供しません。使用している回避策はおそらく最善でしょう。