☰

stdinをtty1からファイルにリダイレクトした後も、プロセスはまだtty1の入力を受け入れます。

tag-icon • tag-icon process stdin
stdinをtty1からファイルにリダイレクトした後も、プロセスはまだtty1の入力を受け入れます。

command < fileファイルの内容をコマンドにリダイレクトするために使用されます。

仮想端末1（/dev/tty1）で実行し、less < file別の仮想端末で実行してlsof -p <pid of the less process>（切り捨て）出力を確認します。

FD    name
----------------
0r    /root/file
1u    /dev/tty1
2u    /dev/tty1
3r    /dev/tty

私はこれを次のように解釈します。

  1. 標準入力は/root/fileです。プロセスは/root/fileでのみ読み取ることができます。
  2. 標準出力は/dev/tty1です。プロセスは/dev/tty1を読み書きできます。 （プロセスに必要な理由はわかりませんが、読む自己出力から...)
  3. 標準エラーは /dev/tty1 です。プロセスは/dev/tty1を読み書きすることができます（つまり、プロセスに権限が必要なのはなぜですか？）読むエラーログから出力されますか？ )
  4. 最後の行は非標準ストリームです。それが何であるかはわかりませんが、プロセスはそれからのみ読むことができます。

質問：stdin/root/fileにもかかわらず、まだlessプロセスと対話できます（たとえば、「/」と入力して検索モードに入り、単語を検索します）。これは、プロセスがまだ現在の仮想端末（/ dev / tty1）から入力を受け入れていることを意味します。stdin/ dev / tty1ではないので、lessキーボード入力を介してプロセスと対話することはできないと思いますか？

答え1

標準入力は/root/fileです。プロセスは/root/fileでのみ読み取ることができます。

標準出力は/dev/tty1です。プロセスは/dev/tty1に読み書きできます。 （プロセスが独自の出力を読まなければならない理由はわかりませんが…）

標準エラーは /dev/tty1 です。プロセスは/dev/tty1を読み書きすることができます（再び、プロセスが出力するエラーログを読み取るにはなぜ権限が必要ですか？）

「stdout」と「stderr」はどちらも同じファイルオブジェクトを指し、同じ「stdin」はからリダイレクトされる前に指します/root/file。つまり、/dev/tty1両方とも次のようになります。繰り返し(2)同じファイル記述子とすべての属性（モード：O_RDWR、ファイルポインタなど）を共有します。ファイル記述子は、複数のポインタが同じ構造を指すことができる（参照計算された）ポインタセットへのインデックスとして考える必要があります。シェルがfcntl(fd, F_SETFL, O_WRONLY)stdinをリダイレクトしても、「stdout」と「stderr」のアクセスモードは変更されません。fileこれは意味がありません。

最後の行は非標準ストリームです。それが何であるかはわかりませんが、プロセスはそれからのみ読むことができます。

これはlessユーザーの対話に使用されます。

問題：標準入力が/ root / fileであるにもかかわらず、lessプロセスと引き続き対話することができます（たとえば、「/」と入力して検索モードに入り、単語を検索します）。これは、プロセスがまだ現在の仮想端末（/ dev / tty1）から入力を受け入れていることを意味します。 stdinが/dev/tty1ではないので、キーボードで入力してlessプロセスと対話することはできません。

/dev/ttyあなたの場合は常にコントロールターミナルを開き、同じデバイス（仮想デバイス - 擬似ターミナル）を参照する魔法のパス/dev/ttyです/dev/tty1。

答え2

特別なケースを展示しています。 fd 0 の入力ストリームでの作業中にlessユーザーと対話するには、入力チャネルが必要です。したがって、キーボードから読み取るために別のファイル（ここではfd 3）を開きます。これは確かに標準入力ではありません。ナレーター（記憶...）：DECのOpenVMSでは、デフォルトでSYS $ INPUTとSYS $ COMMANDを区別します。これは提示された状況をある程度反映します。

関連情報