3秒でわかる
打ち込んだコマンドを解釈して OS に実行させる仲介プログラム。対話操作とスクリプトによる自動化のどちらもこれを通して行います。
もう少し詳しく
どういうものか
シェルは、利用者が入力した文字列を解釈して、対応するプログラムを OS に起動させる仲介役です。Linux や macOS の端末を開いたときに待ち受けているのがシェルで、bash、zsh、fish、dash などの実装があります。プログラムの起動だけでなく、出力の受け渡し、変数の展開、条件分岐や繰り返しといった言語機能も持っています。
なぜ必要か
シェルの価値は、単体では小さな機能しか持たないコマンドを組み合わせて 1 行で目的を果たせる点にあります。パイプ | は前のコマンドの標準出力を次のコマンドの標準入力につなぎ、リダイレクト > は出力をファイルへ流します。この 2 つがあるおかげで、専用ツールを書かずにログ集計やファイル整理が終わります。同じ手順をファイルに書けばそのまま自動化スクリプトになります。
具体例
grep "ERROR" app.log | awk '{print $4}' | sort | uniq -c | sort -rn | head -5
for f in *.txt; do
mv "$f" "${f%.txt}.md"
done
if [ -d /var/log/nginx ]; then
du -sh /var/log/nginx
fi1 行目はエラーログから 4 列目を取り出し、多い順に上位 5 件を出す集計です。
つまずきやすいところ
"$f" と引用符で囲まないと、空白を含むファイル名が 2 つの引数に割れるsh script.sh と bash script.sh では使える構文が違う。配列や [[ ]] は bash 固有cd は実行後のシェルには残らない。子プロセスとして動くためrm * の危険さはここに由来する似た用語との違い
対話的に打つときとスクリプトに書くときで、同じシェルでも挙動が変わる点にも注意が要ります。対話時は履歴やエイリアス、プロンプト表示のための設定ファイルが読み込まれますが、スクリプト実行時はそれらが読まれません。手元では動いたコマンドが cron やデプロイ経由で動かない原因の多くは、エイリアスと PATH のこの差です。スクリプトの先頭で set -euo pipefail を書き、コマンドを絶対パスで指定しておくと事故が減ります。
| 用語 | 指すもの |
|---|---|
| シェル | コマンドを解釈するプログラム |
| ターミナル | 文字を表示し入力を受け取る画面 |
| カーネル | ハードウェアを制御する OS の中核 |
シェルという名前は、カーネル(核)を包む殻という意味から来ています。
覚え方
シェルは注文を受けて厨房に伝える店員です。料理そのものは作らず、伝える先を知っていることに価値があります。