这是好壳的编程习惯使用只读变量只要有可能还是有什么缺点？ 例如，如果我想写一些脚本，由多个脚本文件，它们使用的不可变的文件路径，这将是有意义的声明这样的路径：
readonly LOGS
export LOGS
LOGS="/some/path"
另一个问题是：这是个好主意分裂单片和繁琐太阅读shell脚本代码到单独的文件？ 非常感谢您的回答。
Answer 1:
这听起来像你可能会认为， readonly不超过它确实。 一方面，只读状态不会导出到环境或由子进程继承：
$ declare -rx LOGS=hello
$ LOGS=goodbye
bash: LOGS: readonly variable
$ bash -c 'echo "$LOGS"'
hello
$ bash -c 'LOGS=goodbye; echo "$LOGS"'
goodbye
$
Answer 2:
一般来说，使用只读变量（在任何语言）和模块化程序（在任何语言）是一件好事。
只读变量防止错误的常见来源，并有助于提高可读性和可维护性。 知道你可以依靠变量的值，使您能够更好的理你的计划，并作出有关变量的假设以后 - 东西如果变量是可变的，你不能这样做。
模块化提高了可维护性和可重用性。 多个模块通常意味着更细粒度的单位，可以发现在不同的情况下，再利用，更短的代码更易于阅读，如果你的模块都是独立的，部分之间的相互作用少，可以破坏的修改。
Answer 3:
一个典型的使用只读变量的是TMOUT 。 这个变量设定为非零值将注销后的交互式终端会话TMOUT闲置秒（即，无键盘输入）。 要重写设置打败智能用户，使用readonly ：
readonly TMOUT=60
这样做之后，有没有办法做到：
export TMOUT=0
Answer 4:
我不认为在bash只读变量是有用的。 我不认为这本来是可以避免的通过使变量只读我见过的任何问题。 这些限制违背了庆典的动态特性。 有问题的其他较常见的原因（如mispellings或忘记变量声明为局部），这是不可能的，以防止反正。
如果你想尝试分裂的事情了，只分裂“功能”，而不是仅仅的代码块。 它更容易重用一个小东西，如果你知道“源〜/ myscript.sh”实际上并没有做任何事情。
文章来源: Use of read-only variables in shell scripts [closed]
