将来変更されたときに害を引き起こすことに対してbashスクリプトを強化するにはどうすればよいですか？

そこで、ホームフォルダー（より正確には、書き込みアクセス権のあるすべてのファイル）を削除しました。起こったことは、私が持っていたことです

build="build"
...
rm -rf "${build}/"*
...
<do other things with $build>

bashスクリプトで、不要になった後$build、宣言とそのすべての使用を削除しrmます。ただし、Bashは喜んでに拡張されrm -rf /*ます。うん。

私は愚かだと感じ、バックアップをインストールし、失った仕事をやり直した。恥を乗り越えようとしています。

さて、私は疑問に思う：そのような間違いが起こらないように、または少なくとも可能性が低いようにbashスクリプトを書くためのテクニックは何ですか？たとえば、私が書いていた

FileUtils.rm_rf("#{build}/*")

Rubyスクリプトでは、インタープリターはbuild宣言されていないことについて不平を言っていたので、言語が私を保護します。

rm相関関係に加えて、bashで検討したこと（関連する質問の多くの回答が言及しているように、問題ではありません）：

1. rm -rf "./${build}/"*
   それは私の現在の仕事（Gitリポジトリ）を殺したでしょうが、それ以外は何もありません。
2. rm現在のディレクトリ外で動作する場合、そのバリアント/パラメータ化には相互作用が必要です。（見つかりませんでした。）同様の効果。

それとも、この意味で「堅牢」なbashスクリプトを作成する他の方法はありますか？

set -u

または

set -o nounset

これにより、現在のシェルは未設定変数の展開をエラーとして扱います。

$ unset build
$ set -u
$ rm -rf "$build"/*
bash: build: unbound variable

set -uそして、set -o nounsetされているPOSIXシェルオプション。

空の値はなりませんけれども、エラーを誘発します。

そのために、使用

$ rm -rf "${build:?Error, variable is empty or unset}"/*
bash: build: Error, variable is empty or unset

の展開は、空または未設定${variable:?word}でvariableない限り、値に展開されます。空または未設定の場合、word標準エラーで表示され、シェルは展開をエラーとして扱います（コマンドは実行されず、非対話型シェルで実行されている場合、これは終了します）。:outを残しておくと、underのように、設定されていない値に対してのみエラーがトリガーされset -uます。

${variable:?word}はPOSIXパラメータ拡張です。

これらのどちらも、set -e（またはset -o errexit）が有効でない限り、対話型シェルを終了させません。${variable:?word}変数が空または未設定の場合、スクリプトを終了します。set -uと共に使用すると、スクリプトが終了しset -eます。

2番目の質問については。rm現在のディレクトリ以外では動作しないように制限する方法はありません。

のGNU実装にrmは、--one-file-systemマウントされたファイルシステムを再帰的に削除することを止めるオプションがありますがrm、実際に引数をチェックする関数で呼び出しをラップすることなく取得できると信じています。

追記として： 展開が文字列の一部として発生する場合${build}を$build除いて、次の文字が変数名の有効な文字である場合とまったく同じです"${build}x"。

test/ を使用して通常の検証チェックを提案します[ ]

スクリプトを次のように書いていれば安全でした。

build="build"
...
[ -n "${build}" ] || exit 1
rm -rf "${build}/"*
...

[ -n "${build}" ]チェック"${build}"され、非ゼロ長ストリング。

||bashで論理OR演算子です。最初のコマンドが失敗すると、別のコマンドが実行されます。

このようにして${build}、空/未定義/などでした。スクリプトは終了します（戻りコード1で、これは一般的なエラーです）。

これは、常に偽である${build}ため、すべての使用を削除した場合にも保護されます[ -n "" ]。

test/ を使用する利点[ ]は、他にも多くの意味のあるチェックを使用できることです。

例えば：

[ -f FILE ] True if FILE exists and is a regular file.
[ -d FILE ] True if FILE exists and is a directory.
[ -O FILE ] True if FILE exists and is owned by the effective user ID.

あなたの特定のケースでは、私は過去に「削除」を作り直し、代わりにファイル/ディレクトリを移動しました（/ tmpがディレクトリと同じパーティションにあると仮定しています）：

# mktemp -d is also a good, reliable choice
trashdir=/tmp/.trash-$USER/trash-`date`
mkdir -p "$trashdir"
...
mv "${build}"/* "$trashdir"
...

舞台裏では、これによりトップレベルのファイル/ディレクトリ参照が$trashdirすべて同じパーティション上のソースから宛先ディレクトリ構造に移動し、ディレクトリ構造をたどってファイルごとのディスクブロックをすぐに解放するのに時間を費やしません。これにより、わずかに遅い再起動と引き換えに、システムがアクティブに使用されている間、はるかに高速なクリーンアップが生成されます（/ tmpは再起動時にクリーンアップされます）。

または、/ tmp / .trash- $ USERを定期的にクリーンアップするcronエントリは、多くのディスク領域を消費するプロセス（ビルドなど）の/ tmpがいっぱいになるのを防ぎます。ディレクトリが/ tmpとして別のパーティションにある場合、パーティションに同様の/ tmpに似たディレクトリを作成し、代わりにcronでクリーンアップできます。

ただし、最も重要なのは、何らかの方法で変数を台無しにした場合、クリーンアップが行われる前に内容を回復できることです。

変数が初期化されていない場合、bashパラメータの置換を使用してデフォルトを割り当てます。例：

rm -rf $ {variable：-"/ nonexistent"}

私はいつもBashスクリプトを1行で開始しようとし#!/bin/bash -ueます。

-e手段は、「最初のuncathedで失敗のE rror」。

-u手段は、「最初の使用に失敗U ndeclared変数」。

詳細については、「非公式のBash厳密モードを使用する（Looove Debuggingを使用しない場合）」を参照してください。また、著者は使用することをお勧めしますset -o pipefail; IFS=$'\n\t'が、私の目的ではこれはやり過ぎです。

変数が設定されているかどうかを確認する一般的なアドバイスは、この種の問題を防ぐための便利なツールです。しかし、この場合、より簡単な解決策がありました。

ほとんどの場合、$buildディレクトリのコンテンツを削除するためにディレクトリのコンテンツをグロブする必要はありませんが、実際の$buildディレクトリ自体は必要ありません。したがって、無関係なものをスキップ*するrm -rf /と、デフォルトでは過去10年間のほとんどのrm実装は実行を拒否します（GNU rmの--no-preserve-rootオプションでこの保護を無効にしない限り）。

末尾/もスキップするrm ''と、エラーメッセージが表示されます。

rm: can't remove '': No such file or directory

これは、rmコマンドがに対する保護を実装していない場合でも機能し/ます。

あなたしている言語の用語をプログラミングで思考が、bashはスクリプト言語です:-)だから、全く異なる使用命令全く異なるためパラダイムを言語のパラダイム。

この場合：

rmdir ${build}

以来rmdir非空のディレクトリを削除することを拒否します、あなたは最初のメンバーを削除する必要があります。それらのメンバーが何であるか知っていますよね？これらはおそらくスクリプトのパラメーターであるか、パラメーターから派生したものです。

rm -rf ${build}/${parameter}
rmdir ${build}

ここで、一時ファイルなどのその他のファイルまたはディレクトリを一時ファイルなどに配置するrmdirと、エラーがスローされます。それを適切に処理してから：

rmdir ${build} || build_dir_not_empty "${build}"

この考え方は私にとても役立ちました。