我是否应该在 shell 脚本中的路径变量末尾使用斜杠?

Zen*_*Zen 13 shell shell-script

今天写我的shell脚本的时候。

一个问题突然出现在我的脑海中。

因为cd /target_dircd /target_dir/两者都有效。
我应该在 shell 脚本中的路径变量末尾添加斜杠吗?
比如LOG_PATH=/data/nginx/logsLOG_PATH=/data/nginx/logs/

我在谷歌上做了一些粗略的搜索,但没有找到关于这个的讨论,也许它太基本了?

目前,我真的很难决定选择哪种风格。
但我更喜欢LOG_PATH=/target_dir/风格。
因为当我用 bash 进行自动完成时,它会用斜杠弹出我的结果。

您对此有何看法,为什么?

Mic*_*alH 9

根据 POSIX:

路径名的定义:

用于标识文件的字符串。它具有可选的开头< 斜杠 >字符,后跟零个或多个由< 斜杠 >字符分隔的文件名。路径名可以选择包含一个或多个尾随< 斜杠 >字符。多个连续的< slash >字符被认为与一个< slash >相同,除了正好有两个前导< slash >字符的情况。


ori*_*ion 7

为了安全起见,请包含斜线。连接路径时,这可能会导致多个斜线,但至少可以避免出现问题。

几个例子:rsync如果包含尾部斜杠,则以不同的方式处理路径(它同步目录而不是创建另一个子目录)。目录的符号链接在没有尾部斜杠时有时会以意想不到的方式运行 - 至少 shell 完成会被混淆。您永远不知道您调用的命令/脚本是否依赖于检查斜线是否存在某些特殊行为。它甚至可以使您免于覆盖某些内容。例如,如果您有一个名为 的文件foo,但您错误地认为它是一个目录并想在其中移动某些内容,那么mv bar foo将覆盖该文件(数据丢失,潜在的灾难),但mv bar foo/只会抱怨而什么也不做。

所以总而言之,在大多数情况下这无关紧要,但您应该使用斜线来保护自己,并使人类读者更清楚您打算在脚本中做什么。如果一个变量以斜杠结尾,一个不经意的观察者会立即确定它是指一个目录,如果需要修改它会正确使用它。