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

の違いを探しているだけ 2>&- 2>/dev/null |& &>/dev/null >/dev/null 2>&1 その可搬性non-Bourne shellsのようなtcsh、mkshなど

192 shell  io-redirection  file-descriptors  csh  portability 

ファイル記述子を作成して、出力をリダイレクトできることを知っています。例えば exec 3<> /tmp/foo # open fd 3. echo a >&3 # write to it exec 3>&- # close fd 3. ただし、ファイル記述子がなくても同じことができます。 FILE=/tmp/foo echo a > "$FILE" 追加のファイル記述子を使用する必要がある場合の良い例を探しています。

74 bash  shell  io-redirection  file-descriptors 

昨日、私はこのSOコメントを読みました。このコメントでは、シェル内で（少なくともbash）は>&-「と同じ結果になります」と述べてい>/dev/nullます。 そのコメントは、実際にはその情報源としてABSガイドを参照しています。しかし、そのソースは、>&-構文が「ファイル記述子を閉じる」と述べています。 ファイル記述子を閉じてヌルデバイスにリダイレクトするという2つのアクションが完全に同等であるかどうかは明確ではありません。だから私の質問は：彼らですか？ 表面的には、記述子を閉じることはドアを閉じることに似ていますが、ヌルデバイスにリダイレクトすることはリンボへのドアを開くことです！閉じたドアが見えても、そこから何も捨てようとしないので、この2つはまったく同じようには見えませんが、開いたドアがあれば、できると思います。 言い換えれば、ファイルのすべてのバイトを実際に処理し、それを忘れたファイルに書き込むことを>/dev/null意味するのかどうか、私はいつも疑問に思っていました。一方、シェルが閉じられたファイル記述子に遭遇した場合、私は考える傾向がある（ただし、わからない）疑問が残るかどうかかかわらず、それは単に、何も書かないということはまだだろう読んですべてのバイトを。cat mybigfile >/dev/null/dev/nullcat このコメントは「同じである必要が>&-あります>/dev/null」と言っていますが、それは私にとってそれほど圧倒的な答えではありません。標準またはソースコアを参照するかどうかに関係なく、より信頼できる回答を希望します。

58 shell  file-descriptors 

時折、私は標準IOストリームの1つ（の「等価パス」を指定する必要がありstdin、stdout、stderr）。私は、Linuxで動作する時間の99％以来、私は先頭に追加/dev/取得する/dev/stdinなど、これが「思わ正しいことを行うために」。しかし、1つには、そのような理論的根拠について私はいつも不安でした（もちろん、うまくいかないまで「うまくいくようだから」）。さらに、私はこの操作がどれほどポータブルであるかについて良い感覚を持っていません。 そこで、いくつか質問があります。 Linuxののコンテキストでは、それが安全である（はい/いいえ）と同一視するstdin、 stdoutとstderrして/dev/stdin、/dev/stdoutと /dev/stderr？ より一般的には、この同等性は「十分に移植可能」ですか？ POSIXの参照が見つかりませんでした。

55 io  posix  file-descriptors  portability 

$ ls -l /dev/stdin /dev/fd/0 lrwx------ 1 tim tim 64 2011-08-07 09:53 /dev/fd/0 -> /dev/pts/2 lrwxrwxrwx 1 root root 15 2011-08-06 08:14 /dev/stdin -> /proc/self/fd/0 $ ls -l /dev/pts/2 /proc/self/fd/0 crw--w---- 1 tim tty 136, 2 2011-08-07 09:54 /dev/pts/2 lrwx------ 1 tim tim 64 2011-08-07 09:54 /proc/self/fd/0 -> /dev/pts/2 下のすべてのファイル/devとそのサブディレクトリがすべてデバイスのファイル記述子であるかどうか疑問に思っていましたか？ …

52 linux  devices  file-descriptors 

私はインストールしようとし389-dsています、そしてそれは私にこの警告を与えます： WARNING: There are only 1024 file descriptors (hard limit) available, which limit the number of simultaneous connections. ファイル記述子については理解していますが、ソフト制限とハード制限についてはわかりません。 走るcat /proc/sys/fs/file-maxと戻ってき590432ます。これは、最大590432個のファイルを開くことができることを意味します（つまり、最大590432個のファイル記述子があります）。 しかし、実行するとulimit、異なる結果が得られます。 $ ulimit unlimited $ ulimit -Hn # Hard limit 4096 $ ulimit -Sn # Soft limit 1024 しかし、ハード/ソフト制限ulimitは/proc/sys/fs/file-max何ですか？また、保存された数とどのように関係していますか？

34 linux  file-descriptors  ulimit 

シェルスクリプトでファイル記述子を使用する方法を理解するのは非常に困難です。 私は次のような基本を知っています exec 5 > /tmp/foo したがって、書き込み用にfd 5がfooに添付されます。 exec 6 < /tmp/bar …読書のため。 exec 5>&- …fdを閉じます。 今、これは何をしますか？ #!/bin/bash exec 5 > /tmp/foo exec 6 < /tmp/bar cat <&6 | while read a do echo $a >&5 done 私は理解して&5いるように、fdを閉じますので、各呼び出し後に出力がどのように正常にリダイレクトされていますか？ これはからのコピーパスタです：ここ これをシンプルに使用echo $a > fileすると、はるかに速くなると主張していますが、理解できません。適切なチュートリアルへのリンクをいただければ幸いです。私はグーグルパワーが私に失敗しているようだ。

32 bash  shell-script  io-redirection  file-descriptors 

コンピューターがこのコマンドをどのように読み取るかはよくわかりません。 cat file1 file2 1> file.txt 2>&1 理解できれば、2>&1単に標準エラーを標準出力にリダイレクトします。 そのロジックにより、コマンドは次のように読み取られます。 ファイルfile1とfile2。 stdoutこの操作からに送信しfile.txtます。 に送信stderrしstdoutます。 終わり？ コンピューターが何をしているのかわかりません。私の論理では、コマンドは cat file1 file2 2>&1 > file.txt しかし、これは正しくありません。

29 bash  shell  command-line  io-redirection  file-descriptors 

セキュリティStackExchangeに関するこの回答では、興味深いbash構文を使用してインラインでファイルを生成しています。 openssl req -new -x509 -nodes -newkey ec:<(openssl ecparam -name secp384r1) -keyout cert.key -out cert.crt -days 3650 このビットは特に興味深いものです。 <(openssl ecparam -name secp384r1) ちょうど実行： echo <(openssl ecparam -name secp384r1) 私は戻ってきます /dev/fd/63 そのため、これはファイルの内容で一時ファイル記述子を作成するようです。 これは何と呼ばれていますか？

25 bash  file-descriptors 

私が持っていると言うプロセス1およびプロセス2を。両方とも整数4に対応するファイル記述子を持っています。 ただし、各プロセスでは、ファイル記述子4はカーネルのオープンファイルテーブル内のまったく異なるファイルを指します。 そんなことがあるものか？ファイル記述子は、Open File Tableのレコードへのインデックスであると想定されていませんか？

25 kernel  open-files  file-descriptors 

から man select int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); nfdsは、3つのセットのいずれかで最も大きい番号のファイル記述子に1を加えたものです。 ファイル記述子を決定できる、およびnfdsをすでに持っている場合、の目的は何ですか？readfdswritefdsexceptfds

25 system-calls  file-descriptors 

インタラクティブなbashセッションで実行しています。execを使用していくつかのファイル記述子を作成しました。bashセッションの現在のステータスを一覧表示したいと思います。 現在開いているファイル記述子をリストする方法はありますか？

23 linux  bash  file-descriptors  open-files 

私は今、そうやるので、私はいつも、これを疑問に思いませんが、決して見つけるために時間がかかってきました-使用法がどのようにポータブルここに示したいずれかの/proc/$$/fd/$Nか/dev/fd/$N？私はPOSIXの保証 を理解して/dev/null, /dev/tty, and /dev/console います（この回答に関するコメントを読んだ後、先日それを見つけただけです）が、これらの他のものはどうですか？ 私が知る限り、それらはかなり一般的ですが、どのシステムでそれらを見つけることは期待できませんか？何故なの？どちらか一方を見つける可能性が高いですか？彼らはいつも同じような属性を示しますか？ 私はこれらのデバイスをあらゆる方法でかなり広範囲に使用する傾向があるので、試してみるだけで不足する可能性があるかどうかを知りたいです。 また、上記の質問は私が知りたいと思うものだけであると理解されるべきですが、私は明らかに最初に尋ねなければならないので、私はこの点で最もよく知らないかもしれず、それらは厳しい要件と見なされるべきではありません答え。可能であれば手掛かりをお願いします。

20 process  proc  open-files  file-descriptors  portability 

$ ls -og /proc/self /proc/self/fd lrwxrwxrwx 1 64 Jun 18 11:12 /proc/self -> 32157 /proc/self/fd: total 0 lrwx------ 1 64 Jun 22 2012 0 -> /dev/tty1 lrwx------ 1 64 Jun 22 2012 1 -> /dev/tty1 lrwx------ 1 64 Jun 22 2012 2 -> /dev/tty1 lr-x------ 1 64 Jun 22 2012 …

19 file-descriptors 

exec 3<>/dev/tcp/192.168.0.101/6435192.168.0.101:6435とのTCP接続を確立するために使用しました。そして、pipeコマンドとともにいくつかのメッセージを受信し、送信しました。 次に、TCP接続を終了します。しかし、ss -anpetbash自体が子プロセスをフォークすることなくこの接続を保持していることがわかります。 シグナル9と15をbashプロセスに送信しようとしましたが、ご存じのとおり、bashは自分自身を殺すことはできません。 それで、使用しているPTSを終了せずに、確立したTCP接続を終了できますか（ルートで殺すこともCtrl + Dを送信することもできません）？

17 bash  pipe  tcp  file-descriptors