☰

将路径中每次出现的（可能重叠的）“/./”替换为“/”是否“安全”？

tag-icon • tag-icon shell path
将路径中每次出现的（可能重叠的）“/./”替换为“/”是否“安全”？

/./在符合 POSIX 标准的系统中，是否出现（可能重叠）已被替换的路径/保证通向与原始路径相同的目标？

例子：

#!/bin/bash

shopt -s extglob

some_command -- "${@//\/+(.\/)//}"

更新：

鉴于评论，它不等同，所以我将更新问题：

在符合 POSIX 标准的系统中，是否出现的路径（可能重叠）/././已被替换为/./保证导致与原始路径相同的目标？

答案1

不幸的是，“POSIX 兼容系统”在现实世界中有点模糊。 POSIX 通过标准的不同部分和小节涵盖了命令集、shell、文件系统、系统调用、线程接口等部分内容。许多系统都符合 POSIX 标准，但具有扩展，或者具有 POSIX 标准部件与不兼容或扩展部件并存。

//在某些情况下，在某些系统中，字符串的开头可能会被特殊处理。

对于字符串的其余部分，替换/././为/./或 just/在 POSIX 系统或与 POSIX 兼容子系统接口的系统上应该是等效的。同样，在大多数情况下，除了字符串开头//或多个背对背的正斜杠之外的任何地方都可以折叠为仅/。

然而，有些事情仍然会让你绊倒。虽然 shell 和 FS 可能会/foo//bar像 一样对待/foo/bar，但像指向文件系统之外的文件的 Web 服务器之类的东西可能不会在 URL 端以相同的方式对待它们，而前面的 Web 缓存可能不会。这是因为，虽然从 URL 映射到 FS 中的文件可能看起来很简单，但在某些地方，一种标准和另一种标准并不一定像人们天真的猜测的那样完全映射。 FS 前面的其他网络层可能会导致类似的边缘情况。

/foo//bar特别是，当我的团队发现并且在我们的配置中最初会缓存相同的后端文件，但缓存到具有两个不同缓存 TTL 的两个不同缓存对象时，我特别想起在提供静态文件的 Apache 服务器前面使用 Varnish/foo/bar进行缓存。使用 Varnish 配置重写为规范形式解决了这个问题。

答案2

在路径名解析slashPOSIX 2018 中，描述了以两个字符开头的路径的特殊情况：

如果路径名以两个连续的slash字符开头，则第一个组件尽管两个以上的前导字符应被视为单个字符，但后面的前导slash字符可以以实现定义的方式进行解释。slashslash

.然后，在路径中定义a ：

特殊文件名dot应引用其前身指定的目录。

您可以得出结论，在 POSIX 兼容系统中，应该可以用路径中的/./单个重叠替换所有出现的重叠，/除了那些以//./第一个开头的/./不能被替换的。

/././此外，在这些系统上，用单个替换重叠/./应该毫无例外。

相关内容