可能な限り読み取り専用変数を使用するのは良いシェルプログラミングの慣行ですか、それとも何か欠点がありますか？例えば。私はそれがそのようなパスを宣言するために理にかなって、不変のファイルパスを利用して、複数のスクリプトファイルで構成され、いくつかのスクリプトを記述したい場合：シェルスクリプトでの読み取り専用変数の使用
readonly LOGS
export LOGS
LOGS="/some/path"
別の質問：それは良いアイデアは、モノリシック分割することですと退屈すぎる別のファイルにシェルスクリプトコードを読んで？ あなたの答えに多くの感謝。
あなたはreadonlyが、それだけではありませんと思うかもしれないようですね本当にあります。読み取り専用ステータスは環境にエクスポートまたは子プロセスに継承されていない一つには、：
$ declare -rx LOGS=hello
$ LOGS=goodbye
bash: LOGS: readonly variable
$ bash -c 'echo "$LOGS"'
hello
$ bash -c 'LOGS=goodbye; echo "$LOGS"'
goodbye
$
優れた点ですが、 "。"を使用すると簡単に回避できます。スクリプトを子プロセスとして呼び出すのではなく、 – figtrap
一般的に言えば、（すべての言語で）読み取り専用変数を使用し、プログラムを（任意の言語で）モジュール化することは良いことです。
読み取り専用の変数は共通のバグの原因を防ぎ、可読性と保守性を向上させます。変数の値に頼ることができることを知っていると、プログラムについてより良い理由を説明し、その変数についての仮定を後で行うことができます。
モジュール化により、メンテナンス性と再利便性が向上します。より多くのモジュールは、一般に、異なる状況で再利用できるより細かい単位、読みやすいより短いコード、モジュールが独立している場合は、変更を壊す可能性のある部分間のやりとりが少ないことを意味します。
私はbashのreadonly変数は有用ではないと思います。私は変数を読み込み専用にすることで防ぐことができたと思われる問題は考えられません。このような制限は、bashの動的な性質に反する。とにかく防ぐことが不可能な、他のより一般的な問題の原因（誤字や変数をローカルとして宣言するのを忘れるなど）があります。
コードをまとめるだけでなく、機能を分割するようにしたい場合は、「関数」を分割してみてください。 "source〜/ myscript.sh"が実際に何もしないことが分かっているなら、小さなものを再利用する方が簡単です。
ありがとうございます。しかし、読み取り専用の変数には何の不都合もありませんか？ – user1812379
実際には、読み取り専用変数に値があります。クロスソースされた数十のスクリプトを維持していれば、変数を不変としてマークすることは意味があります！@MarkReedが述べたように、それらは本当に不変ではありませんが、他の誰かがあなたの "もの"を読み始めたら、この変数は変更するつもりはないという意図を持っています！これは本当に便利で、スクリプトをもっと読みやすくします。私は真にグローバル変数で状態を共有することはひどい習慣だと考えていますが、bashはこれを念頭に置いて設計されているわけではありません。 – egelev
読み込み専用変数の古典的な使用方法は、TMOUTです。この変数をゼロ以外の値に設定すると、TMOUT秒間の非アクティブ（キーボード入力なし）の後に対話型端末セッションがログアウトされます。設定を上書きするからスマートユーザーを倒すために、readonlyを使用します。
readonly TMOUT=60
これを行った、実行する方法はありません。
export TMOUT=0
'exec bash'で簡単に回避できます。 '--norc'で' TMOUT'を再設定しないようにする必要があります。 –
これまでのところ、私は良いプログラミングの練習になります任意のbashismを見ていません。きれいなシェルスクリプトを学びたいならば、普通の 'sh'を使ってください。このように簡単に行えないものは、bashで行うべきではありません。 –
読み取り専用の変数は、セキュリティ上の目的で役立ちます。理由を調べるには、コマンドラインでreadonly変数を設定し、それを変更しようとするのが難しいのを見てください。最後にデバッガを使ってBashをハックする必要があることを確認してください（例えば 'gbd attach'）。読み取り専用の変数値を変更します。 –
@A.Danischewski - または単に新しいシェルプロセスを起動します。 –