12

可能な限り読み取り専用変数を使用することは、シェルプログラミングの良い方法ですか、それとも欠点がありますか? たとえば、不変のファイル パスを使用する複数のスクリプト ファイルで構成されるスクリプトを記述したい場合、次のようにパスを宣言することは理にかなっています。

readonly LOGS
export LOGS 
LOGS="/some/path"

別の質問: モノリシックで読みにくいシェル スクリプト コードを別のファイルに分割するのは良い考えですか? ご回答ありがとうございます。

4

4 に答える 4

17

readonlyそれは実際よりも多くのことをしていると思うかもしれません。まず、読み取り専用ステータスは環境にエクスポートされず、子プロセスに継承されません。

$ declare -rx LOGS=hello
$ LOGS=goodbye
bash: LOGS: readonly variable
$ bash -c 'echo "$LOGS"'
hello
$ bash -c 'LOGS=goodbye; echo "$LOGS"'
goodbye
$ 
于 2012-11-15T22:31:15.943 に答える
6

読み取り専用変数の古典的な使用法は、TMOUT. この変数を 0 以外の値に設定すると、非アクティブな状態がTMOUT数秒間続くと (つまり、キーボード入力がない場合)、対話型ターミナル セッションがログアウトされます。賢明なユーザーが設定を上書きできないようにするには、次を使用しますreadonly

readonly TMOUT=60

これを行うと、次のことを行う方法はありません。

export TMOUT=0
于 2012-11-15T22:26:40.353 に答える
5

一般的に言えば、読み取り専用変数を (任意の言語で) 使用し、プログラムをモジュール化する (任意の言語で) ことは良いことです。

読み取り専用変数は、バグの一般的な原因から保護し、読みやすさと保守性を向上させるのに役立ちます。変数の値に依存できることを知っていると、プログラムについてより適切に推論し、後でその変数について仮定を立てることができます。これは、変数が変更可能である場合にはできなかったことです。

モジュール化により、保守性と再利用性が向上します。一般に、モジュールが増えるということは、さまざまな状況で再利用できるきめ細かなユニット、読みやすい短いコード、そしてモジュールが独立している場合、変更を台無しにする可能性のあるパーツ間の相互作用が少なくなることを意味します。

于 2012-11-15T19:29:16.780 に答える
2

bash の readonly 変数は役に立たないと思います。私が見た中で、変数を読み取り専用にすることで防止できた可能性がある問題は考えられません。このような制限は、bash の動的な性質に反します。とにかく防ぐことが不可能な問題の他のより一般的な原因 (スペルミスや変数をローカルとして宣言するのを忘れるなど) があります。

物事を分割したい場合は、コードのチャンクだけでなく、「関数」のみを分割してみてください。「source ~/myscript.sh」が実際には何もしないことがわかっている場合は、小さなものを再利用する方が簡単です。

于 2012-11-15T19:54:54.557 に答える