シェルを知ることは、20%の構文と80%のツールボックスだ

その通り、そしてスクリプトはターミナルをはるかに超えると私も主張したい。

ターミナルでのスクリプトはウィンドウも操作できる（例えばKWinでxdg-open）、ローカルに通知を送ることもできる（例えばnotify-send）、任意のデバイスにも（同じくntfyで）、ダイアログを開くこともできる（例えばkdialog）、他のデバイスを制御することもできる（例えばHomeAssistant APIへのcurl）。つまり本当に全く新しい可能性の世界が開ける…しかもそれは組み合わせ可能だ。

もう一つの文脈として、スクリプトは…最も奇妙で新しいデバイスでも動く。例えばTermuxのおかげでAndroid上のMeta Questでも。OSがあれば必ずどこかにターミナルがあるはずで、あればそこでスクリプトを書ける。つまり…スクリプトは「単に」デスクトップやリモートサーバーのためのものではなく、どこにでもあるのだ。

私の意見では、シェルスクリプトの力にとってスクリプト言語の貢献度はより小さい。私の順位はこうだ：

1. 普遍的なプロセス間インターフェース：標準入力／出力／エラーインターフェースを介した任意のプログラムの合成、そして「すべてはファイルである」という抽象化…このような中核的な設計判断（「すべてはオブジェクトである」はその兄弟のようなもの）なしには、他のどれも不可能だ。

2. 広く普及した標準ユーティリティ：同じ抽象化を介して協調するように設計されたコアユーティリティツールの広範な利用可能性が、僅差で2位だ。同じ計算モデル向けに作られたデフォルトのスクリプト言語とともに。

3. 好みの言語：アクセスのしやすさには重要だが、生の力という点では遠く3位だ。bash、perl、awk、node、clojure（babashka）など何であれ。それはケーキの上のアイシングのようなもので、もし選択の余地がなくてもシェルプログラムは依然として驚くほど強力だろう。証拠はプディングの中にある――「重要なスクリプト」は常に/bin/shだ。

一般的に言えば、shやbashの落とし穴を避けることを学ぶ苦痛は、主にいくつかの基本的な調査読書の問題だ：マニュアル、伝承、警告（私はBashPitfallsが大好きだ）。まあ、あるいはコードをコピペして痛い目を見て学ぶか、運が尽きればrm -rfすべきでないものを消してしまうか。

マニュアルを読むのに1日かそこらを費やすことに代わるものはない。だからそれが大変なのは分かるが、魔法ではないし、自分のペースで一口ずつ象を食べていけばいい。真剣に…試行錯誤の実時間は[…]

彼らが最初のシェルスクリプトの例で何が「間違っている」（というか実際には余計だと）と考えているか、私の推測はかなり近かった。

私は脚注版から「if」を削って、単にこうするだろう

npm install || (echo "boom" && exit)

（echoが失敗した場合に「exit」が実行されないので厳密には等価ではないが、";"よりは私の好みの直感だ）また、細かいことを言えば、「(」はサブシェルを開始する。

記事のより高次の問い、なぜ人々は基本的なファイルやコマンドの管理に自分の主要言語を使わないのか？について。

答えは、よく知られた欠点がすべて文書化されているにもかかわらずPythonが依然として絶大な人気を保っている理由と同じだと思う：電池付き（batteries included）だからだ。

シェル言語には、コマンドを実行し、その入力、出力、終了コードを扱い、グロブや「find」や「xargs」のような高度なツールで深いディレクトリ構造を簡単に辿る、非常に便利で簡潔な方法がたくさん含まれている。だから他のすべては非常に使いにくい。

そしてデフォルトではニッチだ（広く使われるようになるまでは）。だから採用したあなたの好みの言語の専門家でさえ、その言語のシェルに特化したライブラリについては何も知らないだろう。