我正在查看GitHub文档中的一个Bash文件。下面是摘录：
agent_load_env () { test -f "$env" && . "$env" >| /dev/null ; }
agent_start () {
(umask 077; ssh-agent >| "$env")
. "$env" >| /dev/null ; }字符串
我有一些关于编码选择的问题。我不确定这是混乱的代码还是有我可以了解的决策原因：
1.使用>|强制重定向到/dev/null的意义是什么？noclobber不是与/dev/null无关吗？
1.在每个函数的最后一行之后添加一个指针是否有意义？这是否在某种程度上确保了代码安全？
1.第二个函数的奇怪括号格式和另一个函数的单行函数是怎么回事？这只是糟糕的编码标准，还是有shell脚本约定适用于这里？我的直觉是统一格式所有函数的可读性如下：
function myfunc() {
# ...
}型
1条答案
按热度按时间gopyfrb31#
使用的意义是什么>|强制重定向到/dev/null？noclobber和/dev/null不是无关吗？
我同意。
noclobber适用于 * 常规 * 文件，而/dev/null是chardev，所以它不受影响。我会责怪程序员的习惯，这没有造成任何伤害，所以它很好。我可能会认为> /dev/null比>| /dev/null好，如果/dev/null不是恶意系统上的chardev，那么你会得到一个错误，但它可以忽略不计。在每个函数的最后一行后面添加一个后缀有什么意义吗？
命令在shell中用换行符 * 或分号 * 分隔。在
}结束{command grouping之前需要一个分号。例如：{ echo 1; echo 2; }。这在某种程度上保证了代码的安全性吗？
号
第二个函数的奇怪括号格式和另一个函数的单行函数是怎么回事？
真的什么都没有，这可能对你来说很奇怪，可能不适合作者。它只是第一行中的一个子shell，它在本地修改umask，然后是第二行中的另一个命令。
这只是糟糕的编码标准，还是有shell脚本约定适用于这里？
shfmt将其格式化为以下格式，这对我来说看起来更好。字符串
没有太多的shell编码风格标准，比如https://google.github.io/styleguide/shellguide.html，所以请使用常识。
在子shell中运行
umask 077，不影响父shell，并创建其他人无法访问的文件，这绝对是很棒的。对我来说，标准是用shellcheck检查你的脚本。
我的直觉是为了可读性统一格式化所有函数，如下：function myfunc（）{
function myfunc()是ksh和sh两种语法的混合体。它在Bash中只是myfunc()，而不是function。很多人在Bash中使用function，因为它的可读性很好，实际上它不是标准的，但我认为今天所有的POSIX shell实现都接受它。