12

尽可能使用只读变量是良好的 shell 编程实践还是有任何缺点？例如，如果我想编写一些包含多个使用不可变文件路径的脚本文件的脚本，那么声明这样的路径是否有意义：

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

另一个问题：将单片和乏味的 shell 脚本代码拆分成单独的文件是一个好主意吗？非常感谢您的回答。

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

只读变量的经典用法是 with TMOUT。将此变量设置为非零值将在TMOUT几秒钟不活动（即没有键盘输入）后注销交互式终端会话。要阻止智能用户覆盖设置，请使用readonly：

readonly TMOUT=60

完成此操作后，没有办法：

export TMOUT=0
于 2012-11-15T22:26:40.353 回答
5

一般来说，使用只读变量（任何语言）和模块化程序（任何语言）是一件好事。

只读变量可防止常见的错误来源，并有助于提高可读性和可维护性。知道你可以依赖一个变量的值，可以让你更好地推理你的程序，并在以后对这个变量做出假设——如果变量是可变的，你就无法做到这一点。

模块化提高了可维护性和可重用性。更多的模块通常意味着更细粒度的单元可以在不同的情况下重复使用，更短的代码更容易阅读，如果你的模块是独立的，那么可能会破坏修改的部分之间的交互更少。

于 2012-11-15T19:29:16.780 回答
2

我不认为 bash 中的只读变量有用。我想不出我见过的任何问题都可以通过将变量设为只读来防止。这种限制违背了 bash 的动态特性。还有其他更常见的问题原因（如拼写错误或忘记将变量声明为本地变量）无论如何都无法防止。

如果您想拆分事物，请尝试仅拆分“功能”，而不仅仅是代码块。如果您知道“source ~/myscript.sh”实际上并没有做任何事情，那么重用一个小东西会更容易。

于 2012-11-15T19:54:54.557 回答