タグ付けされた質問 「file-descriptors」

ここで説明するように、リダイレクトopen()はファイルへの書き込みに使用します。シェルで作成された内部（？）ファイル記述子があり、必要なときに使用されます。 内部記述子は、スクリプトの全期間またはシェルの存続期間に対して作成されますか？しばらくすると破壊されますか？ 特に、シェル自体が組み込みの操作のために開くファイルのファイル記述子を意味します。各操作で記述子が作成され、ファイルが開かれますか？それらはどれくらいの期間保持されますか？例： #!/bin/bash >>x echo something ...do many other things not related to the file x >>x echo something more 最初の記述子インスタンスは、2番目の操作まで保持されますか？ ターミナルで使用するシェルはどうですか？1つのセッションを数日間、場合によっては数週間開いたままにすることがあります。シェル組み込みで操作したすべてのファイルの記述子はまだ保持されますか？

11 bash  file-descriptors  memory-management 

ファイル記述子6から読み取るには、<&6or </dev/fd/6（別名/proc/self/fd/6）を使用できます。通常、どちらも同じように機能します。しかし、そのファイル記述子がたまたまソケットである場合、奇妙なことが起こります。例えば： $ bash -c 'ls -l /dev/fd/6;cat /dev/fd/6' 6</dev/tcp/localhost/12345 lrwx------ 1 michas michas 64 Jan 10 19:50 /dev/fd/6 -> socket:[315010] cat: /dev/fd/6: No such device or address ここでlsは、記述子が実際に存在することを示しています。ただし、この方法ではデータにアクセスできません。cat <&6代わりに使用すると、すべてが再びうまく機能します。 ファイル記述子にアクセスする両方の方法の違いは何ですか？ 変数で番号が指定されている場合、記述子にアクセスするための良い方法はありますか？（</dev/fd/$fd動作しますが、<&$fd動作しません。） （上記の状況はLinuxでは観察できますが、OpenBSDでは観察できません。-そのファイル記述子はそこで通常の文字デバイスであるようです。）

11 linux  bash  socket  file-descriptors 

「〜より大きい数字」構文（例：）を使用してプログラム出力をリダイレクトしようとする場合foo 2> myfile、ここで考えられる数字は何であり、それらは何を表していますか？ 1は/dev/stdout、2はだと思います/dev/stderr。5と6はどうですか？3、4、または6より大きい数はありますか？

11 io-redirection  file-descriptors  fifo 

これは出力をSTDERRに送信しますが、Ctrl+を伝搬しませんC（つまり、Ctrl+ Cはkillしますsshがリモートはしませんsleep）。 $ ssh localhost 'sleep 100;echo foo ">&2"' これはCtrl+を伝播しますC（つまり、Ctrl+ Cとsshリモートsleepを強制終了します）が、STDERRをSTDOUTに送信します。 $ ssh -tt localhost 'sleep 100;echo foo ">&2"' Ctrl+を伝播させながら、2番目に強制的にSTDERR出力をSTDERRに送信させるにはどうすればよいCですか？ バックグラウンド GNU ParallelはCtrl+ を伝播するために「ssh -tt」を使用しますC。これにより、リモートで実行中のジョブを強制終了できます。ただし、STDERRに送信されたデータは、受信側のSTDERRに送信され続ける必要があります。

11 shell  ssh  signals  file-descriptors  stderr 

これは私が普通に実行するために行うものですgrepし、wcそれを2回スキャンすることなく、ファイルに <file.txt tee >(grep LITERAL) >(wc -l) >/dev/null しかし、これは EXEC LITERAL 32 時々そして 32 EXEC LITERAL またある時には。（からgrepの出力wcは、最初のインスタンスからの出力に先行し、2番目のインスタンスではその逆です。） 一方、リダイレクトとファイル記述子では { { <file.txt tee /dev/fd/3 | grep LITERAL >&4; } 3>&1 | wc -l ;} 4>&1 私はいつも得るようです EXEC LITERAL 32 出力順序が予測可能であることを好みますが、2番目のアプローチで保証されますか？

11 shell  io-redirection  file-descriptors  process-substitution 

迷惑な仮想マシンがいくつかあります。それらにログインするには、vagrant sshコマンドを発行します。通常のsshコマンドでログインしたい。vagrant ssh-config適した設定ファイルを出力します $ vagrant ssh-config Host default HostName 127.0.0.1 User vagrant Port 2201 UserKnownHostsFile /dev/null StrictHostKeyChecking no PasswordAuthentication no IdentityFile /home/cbliard/.vagrant.d/insecure_private_key IdentitiesOnly yes LogLevel FATAL この設定をファイルに出力してssh -Fで使用すると、すべてが正常に機能します。 $ vagrant ssh-config > /tmp/config $ ssh -F /tmp/config default => logged successfully プロセス置換演算子<(cmd)を使用して一時構成ファイルの作成を防ぐと、失敗します。 $ ssh -F <(vagrant ssh-config) default Can't open …

11 bash  ssh  zsh  file-descriptors  process-substitution 

一時ファイルのような一時フォルダーを使用できますか TMP=$(mktemp ... ) exec 3<>$TMP rm $TMP cat <&3 このシェルが終了すると、どちらが自動的に破棄されますか？

10 file-descriptors  tmpfs 

同じユーザーの2つのウィンドウで、bashプロンプトが表示されます。ウィンドウ1で次のように入力します。 $ mkfifo f; exec <f そのため、bashは名前付きパイプにマップされているファイル記述子0から読み取ろうとしていますf。ウィンドウ2で次のように入力します。 $ echo ls > f ここでwindow-1はlsを出力してから、シェルが終了します。どうして？ 次の実験：でもう一度window-1を開きますexec <f。ウィンドウ2で次のように入力します。 $ exec 3>f $ echo ls >&3 上記の最初の行の後で、window-1が起動し、プロンプトを出力します。どうして？上述の第2行の後に、ウィンドウ1のプリントls出力とシェル滞在アライブ。どうして？実際、現在window-2でecho ls > f、window-1シェルを閉じません。 答えは、名前付きパイプを参照するwindow-2からのファイル記述子3の存在と関係がある必要がありますか？

10 file-descriptors  fifo 

私が取り組んでいるbashスクリプト（UbuntuとOS Xで実行する必要があります）では、何百ものコマンドの出力をファイルにリダイレクトする必要があります。それらすべてに 追加&>...するのではなく、単に exec 9>&1 exec 5<>/tmp/some-file.txt exec 1>&5 これまでのところ良好ですが、これらすべてのコマンドの途中で、ファイル記述子を開いたまま、これまでに書き込まれたすべてを読み取る必要があります。 今、Ubuntuで私は簡単にできます cat /dev/fd/5 または tee </dev/fd/5 ただし、OS Xでは何も出力されません（コマンドはすぐに終了します）。 ただし、less両方を使用してファイルの内容を確認できます。 私は使用することで上記の効果（両方のOSで動作する）を達成できます less /dev/fd/5 | tee しかし、それはハックのようです。 では、なぜOS X lessで表示catできないものを表示できるのでしょうか？（または、すべてのBSDの子孫が影響を受けますか？） または、何か間違ったことをしていますか？

10 bash  osx  cat  less  file-descriptors 

6350のPIDで開いているターミナルエミュレータ（T1）があるとします。 別の端末から、次のコマンドを入力します（C1）。 echo "ls\n" > /proc/6350/fd/0 これによりls、T1に新しい行が書き込まれますが、実行されません。どうして？ 私もcat|bashwith を使ってみましたecho "ls\n" > /proc/catid/fd/0が、まだ実行されていません。 コマンドを別の端末にエコーして、コマンドを実行するにはどうすればよいですか？ 可能な答え： $ mkfifo toto; $ bash < toto; $ echo "ls" > toto; この場合、端末に直接直接書き込むことはできません（すべてが、この端末でコマンド（C1）が表示したものと同じように表示されます。

10 terminal  stdout  command  file-descriptors 

私はechoそのPID を示す簡単なスクリプトを書きました。 #/bin/bash while true; do echo $$; sleep 0.5; done 私は38441つのターミナルで上記のスクリプト（何度も何度も言う）を実行してtailおり、別のターミナルでファイル記述子を試行しています。 $ tail -f /proc/3844/fd/1 画面には何も表示されず、までハングし^cます。どうして？ また、すべてのSTDファイル記述子（IN / OUT / ERR）は同じptsにリンクしています。 $ ls -l /proc/3844/fd/ total 0 lrwx------ 1 mg mg 64 sie 29 13:42 0 -> /dev/pts/14 lrwx------ 1 mg mg 64 sie 29 13:42 1 -> /dev/pts/14 …

10 linux  bash  proc  file-descriptors 

私が次のように入力するかどうか私が理解する限り... python -i ... python-interpreterはstdinから読み取り、（明らかに）次のように動作します。 >>> print "Hello" Hello 私がこれをするなら、私はそれが同じことをすることを期待します： echo 'print "Hello"' > /proc/$(pidof python)/fd/0 しかし、これは出力です（実際には空の行になっています）。 >>> print "Hello" <empyline> これは私にはこのように見えます、それは単にprint "Hello"\nそれを受け取ってに書いただけですが、それを stdout解釈しませんでした。なぜそれが機能しないのですか？それを機能させるために何をしなければなりませんか？

10 proc  file-descriptors 

一般的な問題 パイプのチェーンの途中であっても、ユーザーと対話するスクリプトを記述したいと思います。 具体例 具体的には、fileまたはを受け取り、stdin行（行番号付き）を表示し、選択範囲または行番号の入力をユーザーに要求し、対応する行をに出力しstdoutます。このスクリプトを呼び出しましょうselector。それから基本的に、私はできるようになりたいです grep abc foo | selector > myfile.tmp foo含む場合 blabcbla foo abc bar quux xyzzy abc 次に、selector（ターミナルではなく、myfile.tmp！）オプションを表示します 1) blabcbla 2) foo abc bar 3) xyzzy abc Select options: その後入力します 2-3 そして結局 foo abc bar xyzzy abc の内容としてmyfile.tmp。 私はセレクタースクリプトを起動して実行しています。入力と出力をリダイレクトしなければ、基本的には完全に機能しています。そう selector foo 私が望むように動作します。ただし、上記の例のように物事を一緒にパイプする場合、selectorは提示されたオプションをに出力myfile.tmpし、grepped入力から選択を読み取ろうとします。 私のアプローチ 次のように、の-uフラグを使用しようとしましreadた exec 4< /proc/$PPID/fd/0 exec …

10 bash  pipe  file-descriptors  read  interactive 

私はファイル記述子（またはファイルハンドラー）がLinuxシステムのファイルIO手法であることを理解しています。 また、各プロセスには3つの標準ストリーム（つまり、stdin、stdout、stderr）があり、記述子が0〜3のファイルで表されることも知っています。 しかし、私が調べたすべてのプロセスにlsof -p <pid>は、255読み取り権限を持つ追加のファイル記述子があることに気づきました。 この回答から、この機能はBashシェルに固有であることがわかりましたが、回答と参照元の両方で、このファイル記述子の目的が実際に説明されていませんでした。 私の質問： 255ファイル記述子とは何ですか？ 私のBashスクリプトでそれを利用できますか、それとも手動での使用/操作が想定されていない内部動作メカニズムだけですか？

10 bash  file-descriptors 

記述子という単語の選択は、いつも私を奇妙なものとして構成しています。「インデックス」または「id」は、より明白な代替手段のように見えます。「記述子」という単語を選択するための既知の根拠はありますか？ "記述子"は、概念的には数値的というよりもキーっぽいことが多いと思いますが、時には非常に数値的であるため、推測が弱いようです。

9 history  file-descriptors