在shell脚本中使用只读variables

是否使用只读variables的shell编程习惯是否可行或者是否有缺陷? 例如,如果我想写一些由多个使用不可变文件path的脚本文件组成的脚本,那么声明这样的path是否有意义:

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

另一个问题:将单独和繁琐的过度阅读的shell脚本代码分割成单独的文件是一个好主意吗? 非常感谢您的答复。

Solutions Collecting From Web of "在shell脚本中使用只读variables"

这听起来像你可能会认为, readonly做比实际做得更多。 首先,只读状态不会导出到环境中,也不会被子进程继承:

 $ declare -rx LOGS=hello $ LOGS=goodbye bash: LOGS: readonly variable $ bash -c 'echo "$LOGS"' hello $ bash -c 'LOGS=goodbye; echo "$LOGS"' goodbye $ 

一般来说,使用只读变量(任何语言)和模块化你的程序(用任何语言)是一件好事。

只读变量可防范常见的错误来源,并有助于提高可读性和可维护性。 知道你可以依赖一个变量的值,可以让你更好地理解你的程序,并在之后对这个变量做出假设 – 如果这个变量是可变的,那么你不能做的事情。

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

TMOUT只能使用经典的只读变量。 将此变量设置为非零值将在TMOUT秒之后(即没有键盘输入)注销交互式终端会话。 为了击败智能用户覆盖设置,请使用readonly

 readonly TMOUT=60 

完成这个之后,就没有办法做到了:

 export TMOUT=0 

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

如果你想分割的东西,只尝试分割“功能”,而不是只是大块的代码。 如果知道“source〜/ myscript.sh”实际上没有做任何事情,那么重用一个小东西就比较容易。