在Linux上解析$ PATH时我们必须考虑哪些角落案例？

我正在处理一个C程序，它必须走$ PATH才能找到二进制文件的完整路径名，唯一允许的依赖项是glibc（即不需要调用外部程序）。在正常情况下，这只需要通过冒号拆分getenv（“PATH”）并逐个检查每个目录，但是我想确保覆盖了所有可能的转角情况。我应该注意什么陷阱？特别是，相对路径，以〜开头的路径将被扩展到$ HOME，或者包含：char的路径被允许？

来源

2011-08-19 Shea Levy

有一件事让我感到惊讶，PATH中的空字符串表示当前目录。 PATH末尾或开头处的两个相邻冒号或冒号表示当前目录已包含在内。例如，这在man bash中有记录。

它也在POSIX specification。

所以

PATH=:/bin 
PATH=/bin: 
PATH=/bin::/usr/bin

都意味着当前目录是在PATH

来源

2011-08-19 13:11:59

+1在通过源代码检查'which'后，看起来这是唯一的角落案例。首先检查是否给出了完整路径并且该文件是可执行的。然后，它会预先添加路径的每个组件，然后再次检查，用当前目录替换一个空路径组件。 –

遵循规范，'which'和一些通用标准shell的实现应该给出一个相当不错的视角。 – Novelocrat

我不知道这是与一般的Linux问题，但要确保你的代码工作，如果PATH有一些时髦（如UTF-8）编码来处理带有花哨字母的目录。我怀疑这可能取决于文件系统编码。

我还记得一些俄罗斯人的错误报告，他的用户名中有一些花哨的字母（因此他的主目录名称出现在PATH中）。

来源

2011-08-19 13:20:58

不，编码与'PATH'无关。如果一个程序认为它，它是越野车。 –

@R .:有趣的;你有一些规范来支持这一说法吗？我的理解是，为了解析'PATH'，你需要把它看作一个字符序列（而不是一系列'bytes'），因此你需要知道编码。 –

'PATH'中唯一特殊的字符是'：'，所以唯一一次声明可能具有一定的有效性的是传统的面向Windows的CJK编码，但这些编码在Unix上通常被认为是不可用的。 –

这是微不足道的，但我会添加它，因为它尚未提及。 $ PATH可以包含绝对路径和相对路径。如果您通过chdir（2）搜索路径列表到每个目录中，则需要在每次爬网迭代时跟踪原始工作目录（getcwd（3））和chdir（2）。

来源

2011-08-19 17:25:05

现有的回答涵盖了大部分的它，但它是值得的遮还没有回答这个问题的部分：

$和〜$ PATH中的特殊价值。
如果$ PATH没有设置，execvp()将使用默认值。

来源

2011-08-31 20:16:17

在Linux上解析$ PATH时我们必须考虑哪些角落案例？

回答

相关问题