アカウント名:
パスワード:
> スクリプトはある時点でデータの保存場所を「$STEAMROOT」にセットし、後で「rm -rf "$STEAMROOT/"*」を実行する。しかし、データの保存場所が移動されると「$STEAMROOT」が空の文字列を返すため、「rm -rf "/"*」が実行され、予期しない削除が実行されるというものだ。
こう聞くと自分もうっかり書いてしまいそうなミスに見えますが、同じようなケースで事故を回避するベストプラクティスはどんな感じですかね。
bashならスクリプトの先頭に set -u しておく。というか、自分なら未定義の変数を空文字列として展開する言語を使用しない。
今回の場合、変数は未定義ではなく空文字列に定義されていたので、 set -u じゃ防げないと思うよ。ただし、僕は議論をちゃんと追っておらず、どうして空文字列に定義されていたのかは知らないので、理由によっては空文字列に定義する部分で set -u されていれば防げた可能性はあるけど (でもぱっと見ではそうは見えない。どちらかというと set -e の方が関係ありそう)。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
対策 (スコア:1)
> スクリプトはある時点でデータの保存場所を「$STEAMROOT」にセットし、後で「rm -rf "$STEAMROOT/"*」を実行する。しかし、データの保存場所が移動されると「$STEAMROOT」が空の文字列を返すため、「rm -rf "/"*」が実行され、予期しない削除が実行されるというものだ。
こう聞くと自分もうっかり書いてしまいそうなミスに見えますが、
同じようなケースで事故を回避するベストプラクティスはどんな感じですかね。
Re:対策 (スコア:0)
bashならスクリプトの先頭に set -u しておく。
というか、自分なら未定義の変数を空文字列として展開する言語を使用しない。
Re:対策 (スコア:2)
今回の場合、変数は未定義ではなく空文字列に定義されていたので、 set -u じゃ防げないと思うよ。ただし、僕は議論をちゃんと追っておらず、どうして空文字列に定義されていたのかは知らないので、理由によっては空文字列に定義する部分で set -u されていれば防げた可能性はあるけど (でもぱっと見ではそうは見えない。どちらかというと set -e の方が関係ありそう)。