シェルスクリプトの向いているシチュエーション
京都大学のスパコンの運用をしているHPEの手順ミスでデータ滅失したということがあった
bashスクリプト実行中にスクリプトを上書きすると途中位置から実行が継続されて変数を定義していた場合未定義となること
これにより未定義チェックなどやっていない場合予想しない挙動になることがある
この件についてシェルスクリプトの向いているシチュエーションというのはどういうものかというのを改めて考えたい
シェル初期の設計者の使用意図と現代環境の間でインピーダンスミスマッチがある
シェルは基本的に1人で利用することを想定している
メインフレームやPDPなどのミニコンなど
現代は分散環境や複数人で同時利用することも多い
シェルスクリプト自体はシェルコマンドをそのまま順次実行するためのファイル
シェルコマンドを毎回手動で入力しないためであるが根本的にはシェルで手動で入力してるのと動作原理は変わらない
ファイルとパイプというインターフェースでプログラム間を連携することで非常に多様なタスクに対応出来ることは素晴らしく強力ではあるがその強力さゆえに破壊的な失敗をすることも多い
ファイルの破壊的変更を伴うようなプログラム(rm, mv等) は最もミスしやすく最も影響の大きい箇所なのでなるべくならシェルスクリプトでの実行は避ける
破壊的変更を伴わないような操作についてはとても強い
cat, find, ls, awk等
最近のコマンドであれば勝手に複数プロセスに分散し1ホスト内で分散処理してくれることもある
とはいえ複数マシンでの処理は想定されていないものが基本
なので複数マシンで協調したり複数人で作業したりする場合はランタイム自体で調停機能を持つ言語系やタスクcoordinatorを使って意図しない実行を防ぐ必要がある
そう考えるとやはり1人作業、1ホストまでの使用に留めるべきでは?とは思う
複数人で使用がされてきた場合は安全を考慮しスクリプトにリライトするなど