过去的旧建议是对任何涉及 a 的表达式加双引号$VARIABLE，至少在希望 shell 将其解释为单个项目的情况下，否则，内容中的任何空格$VARIABLE都会脱离 shell。
但是，我知道在较新版本的 shell 中，不再总是需要双引号（至少出于上述目的）。例如，在bash：
% FOO='bar baz'
% [ $FOO = 'bar baz' ] && echo OK
bash: [: too many arguments
% [[ $FOO = 'bar baz' ]] && echo OK
OK
% touch 'bar baz'
% ls $FOO
ls: cannot access bar: No such file or directory
ls: cannot access baz: No such file or directory
在zsh，而另一方面，同样的三个命令成功。因此，基于此实验，似乎在 中bash可以省略 内部的双引号[[ ... ]]，但不能省略内部 …
我正在处理将文件位置传递给 scp 子进程的 python 脚本。这一切都很好，但我处于这样一种情况，我可能最终将一个路径与一个文件名连接起来，这样路径中就有一个双 ' /。我知道 bash 不关心您是否有多个文件分隔符，但我想知道如何纠正它。是 bash 去掉了额外的/s 还是真的无关紧要？
我问是因为它会为我节省几行代码来/在连接时检查额外的s。我知道这没什么大不了的，但我也很好奇。我有一个包含行cd //usr（而不是cd /usr）的 bash 脚本，这似乎暗示/在路径中使用多个s可能很重要
是时候解决这个困扰我多年的难题了......
我不时遇到这个问题，并认为这是要走的路：
$(comm "$(arg)")
并认为我的观点得到了经验的强烈支持。但我不再那么确定了。Shellcheck也拿不定主意。两者都是：
"$(dirname $0)"/stop.bash
^-- SC2086: Double quote to prevent globbing and word splitting.
和：
$(dirname "$0")/stop.bash
^-- SC2046: Quote this to prevent word splitting.
背后的逻辑是什么？
（这是 Shellcheck 0.4.4 版，顺便说一句。）
我正在尝试在类 Unix 系统中模拟路径解析过程（请参阅手册页 path_resolution）。
我的操作系统是带有 GNU coreutils 8.7 的 Linux。
为了澄清分辨率中额外尾随 '/' 的含义，我在 shell 中做了以下事情：
mkdir this_is_dir
ln -s this_is_dir this_is_link
rm this_is_link
一切都很好，因为 this_is_link 是一个符号链接，我只是将它删除了。但是在尝试时：
mkdir this_is_dir
ln -s this_is_dir this_is_link
rm this_is_link/
它回响了 rm: cannot remove 'this_is_link/': Is a directory
好吧，我想，尾随的“/”导致了符号链接的跟随。所以，我尝试了另一个命令：rmdir this_is_link/
一个有趣的结果出来了： rmdir: failed to remove 'this_is_link/': Not a directory
不是我所期望的。所以我请我的朋友确认是否可以在他的系统上获得相同的结果。他的 coreutils 版本比我低。而结果是惊人的，无论rm或者rmdir 'this_is_link/'，相同的错误Not a directory发生。
另一个朋友刚刚在他的Mac OS上试了一下，结果是：rm=> '是一个目录'，rmdir=> 目录删除成功，链接仍然存在。
是否有任何关于路径解析的确切行为的规范？