execvp()函数在CLion中运行正常但终端运行提示无此文件或目录

execvp() 报该错误不只有「找不到目标可执行文件」一种诱因，IDE环境和系统shell的环境差异是这类问题的核心触发原因，按以下优先级排查即可：

• 第一优先级：校验PATH环境变量差异
  CLion运行程序时会继承IDE进程自身的PATH配置，若你在IDE的运行配置中额外添加了容器runtime（docker、containerd等）、自定义编译工具链的路径，且未将这些路径写入shell的持久化配置（.bashrc/.zshrc//etc/profile等），就会出现IDE能找到命令、终端找不到的情况。
  验证操作：
  1. 在CLion运行的程序代码中，调用execvp前打印getenv("PATH")的返回值
  2. 在报错的shell终端执行echo $PATH
  3. 逐段对比两个PATH值，将缺失的二进制路径补到shell配置文件中，执行source 对应配置文件生效后重试
     同时可直接在终端手动执行你传给execvp的目标命令，若手动执行也报找不到命令，可直接确认是PATH问题。
• 第二优先级：排查ELF解释器/依赖缺失的假报错
  这是最高频的漏查项：当execvp加载ELF格式的可执行文件时，若内核找不到ELF头中指定的动态链接器（比如/lib64/ld-linux-x86-64.so.2）、或程序依赖的动态库缺失，返回的错误码和「找不到目标文件」完全一致，都是ENOENT，错误提示同样为"no such file or directory"，不会额外提示缺依赖。
  容器场景下这类问题尤其常见：比如你调用的是容器内编译的、使用musl libc的二进制，或是跨架构编译的二进制，CLion可能因加载了内置插件的环境变量（比如跨架构模拟的QEMU_LD_PREFIX、内置动态库路径）可以正常运行，纯净的shell环境没有对应配置就会触发报错。
  验证操作：
  1. 对传给execvp的目标文件执行file 目标文件路径，确认文件架构和当前机器架构匹配
  2. 执行ldd 目标文件路径，若输出中存在not found的依赖项，安装对应依赖即可
• 第三优先级：校验execvp参数格式合法性
  两类参数写法错误会触发随机报错，且IDE的参数解析逻辑可能刚好掩盖问题：
  1. execvp的argv数组必须以NULL作为最后一个哨兵元素，漏写哨兵会导致函数读取栈上的非法内存作为参数，可能随机出现找不到文件的报错
  2. argv的每个元素必须是拆分后的独立参数，比如执行docker run时argv应为["docker", "run", NULL]，若写成["docker run", NULL]，函数会查找名为docker run的文件，必然报错
  3. 若传入的是相对路径的可执行文件，需确认两种场景下的程序工作目录一致：CLion默认工作目录一般是编译输出目录（比如cmake-build-debug），终端运行时的工作目录由你执行命令的位置决定，路径不匹配就会找不到文件。可在调用execvp前通过getcwd()打印当前工作目录对比。

快速调试技巧：在execvp调用分支的失败逻辑中加printf("exec target: %s\n", 目标路径);和perror("exec fail reason");，直接打印实际传入系统调用的参数和错误详情，不要靠主观推测判断问题。

内容的提问来源于stack exchange，提问作者Yechiel Merzbach