ITを整える

中級

パイプとリダイレクトを整える。

＝ `|` や `>` を通るたびデータがどう変わるか、実際に流して見える

`|` や `>` を雰囲気で使っていませんか。プリセットのコマンド列を1段ずつ再生して、サンプルデータが grep・sort・uniq・wc・head を通るたびにどう変わるかを目で追い、続けて `>` `>>` `2>` `2>&1` `<` の行き先の違いを図で確認します。実際のシェルは一切呼び出しません（送信ゼロ）。

🔰 かんたんに言うと

コマンドの結果を次のコマンドへ流す「パイプ（|）」の仕組みを、データが管を流れる図で体験できます。

TLDR — 30秒で分かる

パイプ`|`は前のコマンドの標準出力(1)を次の標準入力(0)に直結するだけ。`>`は上書き・`>>`は追記。`2>&1`は書く順序で結果が変わる（`> out.txt 2>&1`は集約、`2>&1 > out.txt`はエラーが画面に残る罠）。

主な機能

4種のプリセットコマンド列（cat|grep|wc、ps aux|grep、ランキング集計、grep二重）をステップ再生（前へ/次へ/自動再生）
各段の入力・出力行数と中身をリアルタイム表示
同じコマンドに> >> 2> 2>&1 <を付け替え、stdout/stderr/stdinの行き先（画面/ファイル）が切り替わる図
2>&1の「書く順序の罠」を2パターン比較で明示
stdin/stdout/stderrの3本線図をFD番号(0/1/2)つきで常設
すべてブラウザ内で計算・送信ゼロ

常設図　0 / 1 / 2 — この3本を覚えると読める

FD 0　標準入力

stdin

コマンドが読み込む入力。既定はキーボード。< でファイルに差し替え可能。

FD 1　標準出力

stdout

正常な結果の出力先。既定は画面。> >> でファイルへ、| で次のコマンドへ。

FD 2　標準エラー

stderr

エラーメッセージの出力先。既定は画面。パイプ(|)は素通り——普通のパイプは1しか繋がないため、2は流れずそのまま画面に出る。

💡 「パイプで繋いだのにエラーだけ画面に出た」は失敗ではありません。| は既定では標準出力(1)しか次のコマンドに渡さないため、標準エラー(2)は素通りして画面に出るのが正しい動作です。

TRY　① パイプライン・ステップ再生 — データが段を通るたび絞られるサンプルデータのみ・この端末内で計算（送信ゼロ）

プリセットを選ぶ

$ cat access.log | grep 404 | wc -l

ログの中から「404」を含む行だけ残し、その行数を数える定番の3段パイプ。

この段への入力 —行

この段の出力 —行

STEP 0 / 0

💡 パイプ(|)は「前のコマンドの標準出力(1)を、次のコマンドの標準入力(0)に直結する」だけ。ファイルを介さず、メモリ上でデータを受け渡しているイメージです。

TRY　② リダイレクト切替体験 — 行き先はどこ？実際のファイル操作は行いません（送信ゼロ）

同じコマンドに付け替えてみる

$ myscript.sh

実行中のコマンド

myscript.sh

1=stdout / 2=stderr

🖥️

画面

📄

out.txt

⚠ 2>&1 は「書く順序」で結果が変わる

myscript.sh > out.txt 2>&1

①まず1をout.txtへ　②次に2を「今の1と同じ行き先」に合わせる＝2もout.txtへ

→ 標準出力も標準エラーも out.txt に集約される

myscript.sh 2>&1 > out.txt

①まず2を「今の1と同じ行き先」に合わせる＝この時点では1はまだ画面なので2も画面へ　②次に1だけout.txtへ切替

→ 標準エラーは画面に残ったまま。out.txtには標準出力しか入らない

💡 2>&1 は「2番を1番の“今の”行き先に合わせろ」というその場のコピー命令。左から右へ順番に処理されるため、書く順序がそのまま結果を左右します。

ありがちな失敗・3つ

繋げる前に、行き先を意識する。

1

> のつもりが実は上書き、ログを消してしまう

> は毎回ファイルを空にしてから書き込みます。追記したい時に > を使うと、前回までの内容が消えて気づかない事故になりがちです。追記なら >>。
2

パイプで繋げすぎて、後から読めなくなる

grep・sort・uniq・awk・sedを5段も6段も繋ぐと、書いた本人しか追えなくなります。段が増えるほど「途中の出力を一度 tee で確認する」「シェルスクリプトに分けてコメントを書く」判断が要ります。
3

2>&1 を先頭に書いてエラーが画面に漏れる

「エラーもファイルにまとめたい」つもりで 2>&1 > out.txt と書くと、標準エラーだけ画面に残ります。まとめたい時は > out.txt 2>&1 の順で。

LPIC/LinuC

パイプ・リダイレクト・標準入出力／標準エラーの区別は LPIC-1 / LinuC レベル1 の「シェル、シェルスクリプト」領域の頻出テーマです。このページの計算・アニメはすべてあなたのブラウザ内（純JavaScript）で完結し、実際のシェルやファイルシステムには一切アクセスしません（送信ゼロ）。

よくある質問

Q. パイプ（|）とは何ですか？

A. **あるコマンドの標準出力(1)を、次のコマンドの標準入力(0)にそのまま繋ぐ**しくみです。ファイルを介さず、メモリ上でデータを受け渡します。例えば `cat access.log | grep 404 | wc -l` は「ログ全体を出す→404を含む行だけ残す→行数を数える」という3段の加工を1行で表現しています。このページの①ではこの絞り込みが1段ずつ進む様子をステップ再生で確認できます。

Q. `>` と `>>` の違いは何ですか？

A. `>` は**上書き**：出力先のファイルを一度空にしてから書き込みます。既存の内容があれば消えます。`>>` は**追記**：既存の内容はそのまま残し、末尾に継ぎ足します。ログをためたい場面で `>` を使うと、実行するたびに前回までの記録が消えてしまう事故になりがちです。追記したいなら `>>` を選びます。

Q. `2>&1` はどういう意味で、どこに書けばいいですか？

A. `2>&1` は「**標準エラー(2)の行き先を、標準出力(1)の“今の”行き先に合わせろ**」というその場のコピー命令です。左から右へ順に処理されるため、**書く順序で結果が変わります**。`command > out.txt 2>&1` は①1をout.txtへ→②2も（今1が向いているout.txtに合わせて）out.txtへ、で両方out.txtに集約されます。逆に `command 2>&1 > out.txt` は①2を（この時点でまだ画面向きの1に合わせて）画面へ→②1だけout.txtへ切替、となり、標準エラーは画面に残ったままになります。エラーもまとめてファイルに落としたいときは、必ず `> ファイル名 2>&1` の順で書きます。

Q. 標準入力・標準出力・標準エラーとは何ですか？

A. コマンドが持つ3本の入出力です。**標準入力(stdin・FD 0)**はコマンドが読み込む入力で既定はキーボード。**標準出力(stdout・FD 1)**は正常な結果の出力先で既定は画面。**標準エラー(stderr・FD 2)**はエラーメッセージの出力先で、こちらも既定は画面です。パイプ(`|`)は既定では標準出力(1)しか次のコマンドに渡さないため、標準エラー(2)は素通りして画面にそのまま表示されます。これは失敗ではなく正しい動作です。

Q. teeとは何ですか？

A. **画面に表示しつつ、同時にファイルにも保存する**コマンドです。`command | tee out.txt` のように使うと、パイプで次の処理に渡す前に、途中経過をファイルへ書き出して確認できます。パイプを何段も繋いで「今どこで期待した結果と違うのか分からない」となったとき、`tee` を挟んで中間出力を覗く、という使い方が定番です。

Q. パイプで繋げすぎると読めなくなりませんか？

A. なります。grep・sort・uniq・awk・sedなどを5段も6段も1行に繋ぐと、書いた本人以外はもちろん、時間が経つと本人にも追えなくなりがちです。対策は、①`tee`で途中経過を一度確認する、②長くなったらシェルスクリプトに分けて各行にコメントを書く、③このページの①のように「1段ずつ何をしているか」を意識しながら組み立てる、の3つです。1行の長さと可読性はトレードオフだと割り切るのがコツです。

Q. このツールは何かを送信しますか？

A. 送信しません。パイプラインのステップ再生もリダイレクトの図解も、すべてこのページを開いたブラウザの中だけで完結する純粋な計算です。サンプルデータはページに固定で埋め込まれた架空のログ・プロセス一覧・名前リストのみを使い、実際のファイルやシェルには一切アクセスしません。

入力値はURLの「#」以降に入るためサーバーには送信されません。リンクを開くと同じ状態を復元します。