在 shell 脚本中使用只读变量



尽可能使用只读变量是好的shell编程习惯还是有任何缺点? 例如,如果我想编写一些由多个使用不可变文件路径的脚本文件组成的脚本,像这样声明路径是否有意义:

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

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

听起来你可能会认为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"实际上没有任何作用,那么重用一个小东西会更容易。

相关内容

  • 没有找到相关文章

最新更新