which和whereis能满足80%日常需求，但查真实生效配置或排查多版本问题时需结合dpkg -l/rpm -ql、ps aux找-c参数、nginx -t输出等方法，因包管理器路径不等于运行时实际加载路径。

直接看 which 和 whereis 就能解决 80% 的日常需求；但如果你要确认真实生效的配置或排查多版本共存问题，光靠这两个命令会漏掉关键路径。

查可执行文件位置：用 which 最快，但只认 $PATH

which 只搜索环境变量 $PATH 中列出的目录，返回第一个匹配的二进制路径。它不关心源码、配置或手册页，也不管你装没装全。

• 适合快速验证命令是否可用、当前调用的是哪个版本（比如 which python3）
• 如果软件是源码编译后手动加到 $PATH 的（如 /usr/local/bin/nginx），它能立刻定位
• 但若该命令被 alias 或 shell function 覆盖，which 可能返回错误结果；此时改用 command -v nginx 更可靠
• 权限不足时可能静默失败，建议搭配 type -P 验证（type -P mysql）

查完整资源分布：whereis 显示二进制、源码、man 页三类路径

whereis 不依赖 $PATH，而是查系统预设的常见目录（如 /bin、/usr/share/man 等）。它输出的路径往往反映包管理器的“标准布局”。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 例如 whereis nginx 可能返回：nginx: /usr/sbin/nginx /usr/lib/nginx /etc/nginx /usr/share/nginx
• 其中 /etc/nginx 是配置目录，/usr/share/nginx 是静态资源（如默认首页），但这些不一定是当前服务实际加载的路径
• 对未通过包管理器安装的软件（如自己 make install 到 /opt/myapp），whereis 很可能完全找不到
• 它不递归搜索子目录，所以像 /usr/local/nginx/conf/nginx.conf 这类自定义路径不会出现

确认包管理器安装来源：用 dpkg -L 或 rpm -ql

只有当你确定软件是通过系统包管理器安装的（apt/yum/dnf），才该用这类命令。它们读取数据库记录，能列出该包安装的所有文件，权威性最高。

• Debian/Ubuntu：dpkg -L nginx —— 输出所有文件路径，包括 /etc/nginx/、/usr/share/doc/nginx/ 等
• RHEL/CentOS/Fedora：rpm -ql httpd
• 但注意：dpkg -L 和 rpm -ql 返回的是“安装时写入的路径”，不是运行时实际加载的配置。比如你用 nginx -c /opt/custom.conf 启动，生效的就不是 /etc/nginx/nginx.conf
• 先用 dpkg -S $(which nginx) 或 rpm -qf $(which nginx) 确认它确实属于某个包，再查列表，避免白忙

绕过包管理器：当软件是源码编译或手动解压时

这时 which 和 whereis 可能只告诉你二进制在哪，但整个安装树（配置、日志、模块）得靠其他方式拼凑。

• 看进程启动参数：ps aux | grep nginx，重点找 -c（指定配置）、-p（指定前缀路径）等参数
• 检查配置文件里是否硬编码路径：比如打开 $(which nginx) 对应的 nginx.conf，搜 include、pid、error_log 等指令，常带绝对路径
• 用 find /usr/local -name "*nginx*" 2>/dev/null 或 locate nginx.conf（需先 sudo updatedb）辅助定位
• 动态库路径也能反推：ldd $(which nginx) | grep "not found" 可暴露缺失依赖，而正常路径往往指向同级 lib 目录

最易被忽略的一点：同一个软件名，可能同时存在包管理器安装版、源码版、容器内版、甚至用户私有 ~/bin 下的版本。不先确认来源就查路径，等于在多个平行宇宙里找同一扇门。