タグ付けされた質問 「pipe」

データが通過する速度を測定できるシェルコマンドがあるため、パイプ内のコマンドの出力速度を測定できます。代わりに： $ somecommand | anothercommand 次のようなことができます： $ somecommand | ??? | anothercommand そして、スループット統計（バイト/秒）がstderrに出力されると思います。しかし、私は一生その命令が何であったかを思い出すことができません。

35 command-line  pipe  performance  io 

次の2つのコマンドの違いを知りたかった 2>&1 > output.log そして 2>&1 | tee output.log 同僚の1人が2番目のオプションを使用してリダイレクトするのを見ました。私は2>＆1が何をするか知っています、私の唯一の質問は、単純なリダイレクト「>」演算子を使用できるteeを使用する目的は何ですか？

35 shell  io-redirection  pipe 

テキストを作成して、そのテキストを別のコマンドにパイプする必要がある場合があります。私の通常のワークフローは次のようになります。 vim # I edit and save my file as file.txt cat file.txt | pandoc -o file.pdf # pandoc is an example rm file.txt これは面倒で、bashスクリプトを学習しようとしているので、エディターを起動するコマンドを作成し、エディターがパイプを閉じるとエディターの出力をstdoutに書き込むことでプロセスをより簡単にしたいと思います。その後、コマンドをとして実行できるようになりますquickedit | pandoc -o file.pdf。 これがどのように機能するかはわかりません。上記の正確なワークフローに加えていくつかの追加を行うことで、これを自動化する関数を既に作成しました。ファイル名として機能するランダムな文字列を生成し、関数が呼び出されたときにそれをvimに渡します。ユーザーがファイルを保存してvimを終了すると、関数はファイルをコンソールに出力してからファイルを削除します。 function quickedit { filename="$(cat /dev/urandom | env LC_CTYPE=C tr -cd 'a-f0-9' | head -c 32)" vim $filename cat $filename rm …

34 vim  pipe  stdout 

ユーザーインタラクティブシェルを起動する実行可能ファイルがあります。シェルの起動時に、最初にいくつかのコマンドを挿入してから、ユーザーにインタラクティブセッションを許可します。私はこれを簡単に使用できますecho： echo "command 1\ncommand 2\ncommand3" | ./shell_executable これはほとんど機能します。問題は、コマンドのエコーが完了すると、プロセスのstdinにフィードしているエコーコマンドがEOFに達することです。このEOFにより、シェルはすぐに終了します（シェルでCtrl + Dを押したかのように）。 後でEOFを発生させずにこれらのコマンドをstdinに注入する方法はありますか？

33 shell-script  pipe  stdin 

誰かがコマンドラインでパイプの概念を学ぶのを手伝っていたら、どの例を使用しますか？実際に出てきた例は次のとおりです。 cat whatever.txt | less それは最良の例ではないように感じます。つまり、1つのステップしかないからです。良いが、基本的な使用は何ですか|何ですか？ 理想的には、ここで紹介する例では、独立して実行でき、一緒にパイプで表示できる出力自体を備えたプログラムを使用します。

33 command-line  pipe 

ホームファイルのパッケージを削除したかったのですが、ファイル名が長すぎました（google-chrome-stable_current_i386.deb）。そこで、コマンドを使用しls|grep chrome|rmてファイルをgrepにパイプし、chromeファイルを除外してから削除することにしました。それはうまくいきませんでしたので、私はこれをどのように行うことができるかを見たいです。

33 grep  pipe  ls  rm 

たとえば、次のような名前付きパイプを作成しました。 mknod myPipe p そして、いくつかのプロセス（たとえば、いくつかのサーバー）から読み取ります。例として、tailを使用しました。 tail -f myPipe 複数のクライアントプロセスがメッセージを書き込む場合（たとえば、次のようにecho "msg" >> myPipe、メッセージがインターリーブされる可能性があります： <beginning of message1><message2><ending of message1> または、名前付きパイプへの書き込みプロセスはアトミックですか？

32 linux  pipe 

の動作を模倣-execする+オプションを選択できることを理解していますxargs。あるフォームを他のフォームよりも好む状況はありますか？ 個人的には、パイプの使用を避けるためだけに、最初の形式を好む傾向があります。開発者はfind適切な最適化を行ったに違いない。私は正しいですか？

32 bash  find  pipe  xargs 

Element_queryクエリの結果を含む名前のファイルがあります： SQL> select count (*) from element; [Output of the query which I want to keep in my file] SQL> spool off; シェルコマンドを使用して1行目と最後の行を削除したい。

31 shell  sed  awk  grep  pipe 

ファイルはによって順次ダウンロードされていwgetます。 でアンパックを開始するとcat myfile.tar.bz2 | tar -xj、何が速いかに応じて、正しくアンパックされるか、「Unexpected EOF」で失敗する場合があります。 ファイルを "cat and follow"する方法、つまりファイルの内容をstdoutに出力しますが、EOFで終了せず、代わりにそのファイルにサブスクライブし続け、データの新しい部分を出力し続けます。ライターであり、N秒以内に再オープンされません。 @arielCoの回答に基づいて、cat_and_followスクリプトを作成しました。これは、ファイルが書き込み用に開かれなくなったときにも終了します。tail

31 files  pipe  cat  tail  open-files 

|最初のコマンドの結果を別のコマンドに送信するために使用されることに気付きました。名前に一致するすべてのプロセスを強制終了します。 これはpgrepが通常行うことです： $ pgrep name 5089 5105 そして、複数の引数が動作するようですkill： sudo kill 5089 5105 しかし、これは間違っています： pgrep name | kill それで、それを適切に行う方法は？

31 shell  pipe  arguments 

各grepコマンドで、結果を異なる色で強調表示しようとしています。私はこのような行で手動でそれを行うことができます： ls -l GREP_COLORS='mt=01;32' grep c | GREP_COLORS='mt=01;31' grep o | GREP_COLORS='mt=01;34' grep n | GREP_COLORS='mt=01;36' grep f すべてのc文字が緑で強調表示され、すべてのo文字が赤で強調表示されます。 この例が機能するためには、常に--color=alwaysgrepコマンドを使用する必要があり ます。私はこれを私の中で設定した.bashrc ので、grepは常に色を持っています： export GREP_OPTIONS='--color=always' 私が達成しようとしているのは、この機能をエイリアスでラップgrepして、GREP_COLORS毎回呼び出して異なる値を設定できるようにすることです。パイプされた新しいgrepごとに複数のシェルの考慮事項を理解し、いくつかのファイル（各色に1つ）を作成してこれを克服しようとして、既に使用されていることを示します。 私はいくつかの試みをしましたが、奇妙なことに、これは「最高」に機能するようです。私はこれを持っています.bashrc： alias mg="mygrep" mygrep(){ # define possible colors COLORS=("01;32" "01;31" "01;34" "01;36") COUNTER=0 NUM=0 # as long as the color has already been used, keep …

30 bash  shell  grep  pipe  bashrc 

で一時ファイルを作成するのが最善であると認識していますがmktemp、名前付きパイプはどうですか？ 私は物事を可能な限りPOSIX準拠にすることを好みますが、Linuxのみが許容されます。私が書いているように、バシズムを避けることは私の唯一の厳しい基準dashです。

30 linux  shell  security  pipe 

ここに私が考えたいくつかのオプションがありますが、どちらが正しいかはわかりません。 パイプからの読み取り中にI / Oエラーが発生しました。 パイプのもう一方の端に書き込むプロセスが失敗して終了しました。 パイプに書き込むことができるすべてのプロセスがパイプを閉じました。 パイプの書き込みバッファがいっぱいです。 ピアは、二重パイプのもう一方の方向を閉じました。 パイプから読み取ることができるプロセスがないため、書き込みに失敗しました。 システムコールがEPIPEエラーを返しましたが、エラーハンドラがインストールされていませんでした。

30 pipe 

FIFOは名前付きパイプだと聞きました。そして、それらはまったく同じセマンティクスを持っています。一方、Unixドメインソケットはパイプに非常に似ていると思います（使用したことはありませんが）。だから、彼らはすべてLinuxカーネルの同じ実装を参照しているのだろうか。何か案が？

30 pipe  linux-kernel  socket  ipc  fifo