为何类Unix系统命令行支持通过当前目录相对路径执行程序？

这其实是Shell处理命令查找的核心逻辑差异导致的，我来给你拆解清楚：

1. Shell的命令查找规则 #

Shell在解析你输入的命令时，会做一个关键判断：

• 如果命令字符串不包含路径分隔符/（比如a、ls）：Shell会遍历PATH环境变量里的所有目录，挨个查找是否存在同名的可执行文件，找到就执行，找不到就报错「command not found」。默认情况下PATH是不包含当前目录.的，所以直接打a会找不到。
• 如果命令字符串包含路径分隔符/（不管是绝对路径/home/user/temp/a，还是相对路径./a、temp/a）：Shell会直接把它当作一个文件路径处理，不会去查PATH——只要这个路径对应的文件存在、且你有执行权限，就能直接运行。

你测试的temp/a属于第二种情况，所以完全可以正常执行，和PATH没有任何关系。

2. 为什么不支持直接运行exe？ #

默认不把当前目录加入PATH是出于安全和避免歧义的考虑：

• 假设你进入一个陌生目录，里面有个叫ls的恶意可执行文件，如果PATH包含.，你输入ls时会优先执行这个恶意文件，而不是系统的/bin/ls，这会带来安全风险。
• 日常使用中也可能不小心创建和系统命令同名的脚本，导致执行结果不符合预期。

3. 和execv系统调用的逻辑差异 #

你提到libc的execv函数支持绝对和相对路径，这和Shell的行为不冲突：

• execv是系统调用，它的参数是明确的文件路径（不管是绝对还是相对），内核会直接根据这个路径去查找文件执行。
• 而Shell的命令解析是在用户态做的一层封装：对于无/的命令，Shell帮你做了「在PATH里找」的逻辑；对于带/的命令，Shell直接把路径传给execv类的系统调用。这是Shell的设计逻辑，不是系统调用的限制。

4. 关于「完整路径和相对路径运行结果不同」的可能原因 #

你遇到的这种情况，常见的诱因有这几个：

• 动态库加载差异：很多程序会用$ORIGIN（动态链接器的内置变量）来加载相对自身路径的动态库。用temp/a运行时，$ORIGIN是./temp；用完整路径/home/user/temp/a运行时，$ORIGIN是/home/user/temp，如果这两个路径下的库版本不同，就会导致运行结果不一样。
• 程序内部的路径计算：有些程序会通过readlink("/proc/self/exe")（Linux）或_NSGetExecutablePath（macOS）获取自身的绝对路径，然后基于这个路径去读取配置文件、资源文件等。相对路径和完整路径运行时，程序获取到的自身路径不同，就会加载不同的文件，导致结果差异。

内容的提问来源于stack exchange，提问作者v.v