UNIX Cafe 第111回
なぜ技術書は「読みづらい」のか？
リファレンス本を開くと、こんな風に書かれています。
「
;はコマンドの区切りであり、{ }はコマンドをグループ化するものである」
正直、これだけでは「なぜ括弧が必要なのか」が見えてきません。しかし、この無機質な記述の裏には、コンピュータの歴史を変えた一つの大きなルールが存在します。それが POSIX（Portable Operating System Interface） です。
舞台裏：POSIXという「世界の共通語」
かつて、UNIXの世界はバラバラでした。メーカーごとにコマンドの動きが少しずつ異なり、あっちで動くスクリプトがこっちでは動かない……そんな暗黒時代があったのです。
そこで、「どんな環境でも同じように動くようにしよう」と決められた国際標準規格がPOSIXです。
- 標準ルール（POSIX）： 法律のようなもの。
- 実装（UNIX / Linux）： そのルールに基づいて作られた各OS。
リファレンス本が「コマンド」や「リスト」や「パイプライン」といった堅苦しい言葉の定義を崩さないのは、「どのOSを使っている読者に対しても、嘘にならない正確なルール」を伝えようとしているからです。
私たちが、UNIXやLinuxのコマンドを、どこから学んでも迷子にならないのは、この厳格な「POSIX準拠」という地図があるおかげなのです。
核心：シンプル解説（ルールを味方にする）
この「POSIX準拠」という厳格なルールの中で、セミコロンと波括弧は明確に役割が分かれています。
{ cd /dir; ls; } （運命共同体の結成）
波括弧で囲むことで、シェルはこれを「一つの大きなコマンド（複合コマンド）」として認めます。チームになったことで、全員の出力をまとめて一つのファイルに保存したり、次の処理へ渡したりすることができるようになります。
cd /dir; ls （独立した個人の集まり）
POSIXでは、これは単に「1つ以上のパイプラインが並んだもの（リスト）」と定義されます。ただ順番に並んでいるだけで、お互いに干渉しないドライな関係です。
この2つの違いを一言で言えば、「独立した個人の集まり」か、「運命共同体のチーム」か、という違いです。
実戦：現場でどう使うか
例えば、サーバーの作業ログを記録するシーンを想像してください。
# バラバラ（POSIXリスト）: 最後の結果しか保存されない
cd /var/log; tail -n 10 syslog > output.txt
# チーム（複合コマンド）: 全体の流れを一括で保存できる
{ cd /var/log; tail -n 10 syslog; } > output.txt「とりあえず並べる」のではなく「目的のために束ねる」。この使い分けができるようになると、シェルとの対話がぐっとスムーズになります。
UNIX ユーザーのひとりごと：「POSIX準拠」というルールへの敬意
POSIXのルールは、時に { の後のスペースを要求したり、末尾の ; を強制したりと、少し口うるさい親戚のように感じるかもしれません。
でも、この「面倒な決まり事」を守ることで、あなたが今日書いたスクリプトは、10年後の別のLinuxマシンでも、遠く離れたBSDサーバーでも、同じように動いてくれます。リファレンス本の4行の向こう側には、そんな「技術の普遍性」への敬意が詰まっています。
まとめ | セミコロンと波括弧、その「距離感」の違い
1. cd /dir; ls （単純な連続実行）
これは単に「1つ目のコマンドが終わったら、2つ目を実行せよ」という命令です。
- 動作: 現在のシェル環境で
cdし、その後にlsを実行します。 - 影響範囲: 2つのコマンドは独立しています。
- パイプラインでの挙動: セミコロンは「独立」を重んじます。
cd /dir; ls | grep "test"cd /dir; ls | grep "test" と実行した場合、パイプ（|）が繋がるのは 直前の ls だけ です。
最初の cd はパイプの存在を知らず、自分の仕事を終えたらすぐに列から離れてしまいます。そのため、grep が探せるのは ls の結果の中に限られます。
2. { cd /dir; ls; } （グループコマンド）
波括弧 { } で囲むと、中のコマンド群が「1つのコマンド」としてシェルに認識されます。
- 動作: 現在のシェル環境で実行される点は同じですが、全体が「1つのユニット」になります。
- リダイレクトやパイプの共有:波括弧は「一丸」となって進みます。
{ cd /dir; ls; } > output.txt{ cd /dir; ls; } | grep "test" と書けば、中身の出力はすべて一つの流れとしてパイプに注ぎ込まれます。
チーム全員の声を、次のコマンド（この場合は grep）へ確実に届けることができるのです。
※もし、途中で発生した「エラーの声（標準エラー出力）」まで一滴残らず保存したい場合は、末尾に 2>&1 というおまじないを添えて、窓口をひとつにまとめてあげましょう。
POSIXの作法（なぜその隙間が必要なのか）
注意点（POSIXの作法）：シェルを迷子にさせないために
実はシェルにとって、波括弧は少し「見分けにくい」繊細な存在です。 そのため、始まりの { の後には スペース を、終わりの } の直前には セミコロン ;（または改行）を置いてあげてください。
これがないと、シェルは括弧と中身を地続きの「一つの長いコマンド名」だと勘違いしてしまいます。 たとえば {ls;} と書くと、シェルは ls ではなく「{ls;」という名前の未知のコマンドを必死に探し回り、見つけられずにエラーを吐き出してしまうのです。
| 特徴 | cmd1; cmd2 | { cmd1; cmd2; } |
| 呼び方 | コマンドリスト | グループコマンド |
| 実行環境 | 現在のシェル | 現在のシェル |
| 一括リダイレクト | 不可（最後のコマンドのみ） | 可能 |
| 一括パイプ | 不可（最後のコマンドのみ） | 可能 |
| 主な用途 | 手入力での連続実行 | スクリプト内での出力制御 |
歴史の肖像を、あなたのスクリプトに
リファレンス本に書かれた無機質な一行が、今日から少しだけ誇らしげに見えてきたら幸いです。
POSIXという偉大なルールは、決して私たちを縛るためのものではありません。どんな時代、どんな環境でも、あなたの言葉（コード）が正しく届くように守ってくれる「約束事」なのです。
次はあなたのターミナルで、この「運命共同体」の力を試してみてください。コーヒーを飲み終える頃には、シェルの頑固なエラーさえも、少し愛おしく感じられるかもしれません。
