標準出力を分岐して同時に複数のコマンドの標準入力にパイプする方法です。 次の例では、command1の標準出力を複数のストリームに分けて、それぞれcommand2の標準入力とcommand3の標準入力に渡しています。 mkfifo temp_fifo <temp_fifo command2 & command1 | tee temp_fifo | command3 rm temp_fifo 2行目は cat temp_fifo | command2 & と置き換えることもできます。
![標準出力を分岐して同時に複数のコマンドの標準入力にパイプする](https://cdn-ak-scissors.b.st-hatena.com/image/square/932d215ec002b52bb0fc359dba379293ff7221cd/height=288;version=1;width=512/http%3A%2F%2F3.bp.blogspot.com%2F_MAUjtDx4OL8%2FTG38ZjvV56I%2FAAAAAAAAAYE%2F-qWZKlQQu30%2Fw1200-h630-p-k-no-nu%2Ficn_Terminal_128.png)
$ hoge > source.txt $ grep -v \# source.txt > code.txt $ grep \# source.txt > comment.txt のように一時ファイルを作ればいいのだが、こんなことをせず2箇所に直接hogeの出力を渡したくなった。 出力の分岐といえばteeコマンド。本来の出力先はファイルだが、これをストリームに出力するようにしてあげよう。 名前付きパイプ 名前付きパイプでcode.txtとcomment.txtを同時に得る方法。
はい、どーも。モバイルアプリサービス部の吉田です。 今回は、Oracle JDK8のサポート状況について、少し調べる必要があったのでこれについて調べてみました。 Oracle JDK8にはいつまでパッチが提供されるの? おそらく皆さんが使ってるJDK8は、Oracle JDK8が多いものと思います。 Oracle JDKに対する、バグ・セキュリティに関するパッチは、Oracleから無償で提供されています。 これが 2019年1月 までです。 ソースとしては こちらのページに オラクルは Java SE 8 の公式アップデートの提供と自動更新(auto update)を、個人ユーザーには2020年12月まで、商用ユーザーには2019年1月まで、引き続き提供します。 とあります。ですので、2019年1月末以降、Oracle JDK8に対するバグ・セキュリティパッチは提供されなくなります。 有償
「ビッグデータ」が「notデータ」でAIマジギレ!? “残念なAI導入”を卒業するには:マスクド・アナライズのAIベンチャー場外乱闘!(1/4 ページ) 前回記事では、はま寿司でPepperが有効活用されている理由や、ロボットと人間のコストパスフォーマンス比較などについて考えました。コストの問題は、Pepperに限らずAI(人工知能)でも考えなくてはいけません。 同じく前回記事の冒頭で触れたハロウィーンですが、AIと同じように右肩上がりでブームが続くのでしょうか? ここ数年ハロウィーンの市場規模は頭打ちですし、繁華街における騒動や散乱するごみが問題視されています。こうした「ブームに踊らされる日本人」については記事の最後であらためて考えたいと思います。 前回記事→大激突! Pepper vs パートのおばちゃん “コスパ頂上決戦” AIの話に戻りましょう。米調査会社ガートナーによると、AIは
こんにちは。去年の今頃は Rust を書いていました。 インフラストラクチャー部データ基盤グループの id:koba789 です。 背景 クックパッドではデータ基盤の DBMS として Amazon Redshift を利用しています。 既存のデータ基盤について詳しいことは クックパッドのデータ活用基盤 - クックパッド開発者ブログ を参照してください。 今まで、ログは数時間に1度、定期実行ジョブで Redshift 内のテーブルにロードしていました。 ロードジョブの実行間隔が "数時間" と長めなのは、Redshift のトランザクションのコミットが遅いためです。 クックパッドでは数百ものログテーブルがあるため、仮に1分おきにすべてを取り込もうとすると秒間数回以上のコミットを行わなければなりません。 このような頻繁なコミットは Redshift 全体のパフォーマンスを悪化させてしまいます
Docker Meetup Tokyo #26での発表資料です。 いろいろなコンテナランタイムについて、機能、セキュリティ、パフォーマンス、開発動向に着目して比較調査および性能測定を行ないました。 ぜひ以下の記事も合わせてご参照ください。 『今話題のいろいろなコンテナランタイムを比較してみた[Docker Meetup Tokyo #26発表レポート]』 https://medium.com/nttlabs/container-runtime-d3e25189f67a unikernelベースのイメージの作り方などの技術的な話題は付録にも記載しましたが、近々、別の形でもまとめようと考えています。 [留意] 本資料中の性能測定は、コンテナランタイムのCRI命令処理(Podやコンテナの作成から削除までの各ステップのCRI命令)の性能を測定したものです。 それらCRI命令への処理はあくまでもコン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く