手敲能跑脚本里却 command not found:一次 Linux PATH 与 shell 环境的排查复盘

2023 年,一个"同一条命令,我手敲能跑、脚本里就报 command not found"的问题,把我对"一台机器上,装了一个程序"这件事的理解,彻底重置了一遍。那天我写了个部署脚本 deploy.sh,里头有一行 node build.js。我在终端里,一行一行地手动执行,跑得顺顺当当,node 跑得好好的。我很满意,把这脚本挂进了 crontab,让它每晚自动跑。第二天一看日志——脚本失败了,就一行刺眼的字:deploy.sh: line 8: node: command not found。找不到 node 命令。我懵了。我【现在】就在这台机器上,我敲 node -v,它清清楚楚回我 v18.16.0;我敲 which node,它告诉我 node 在 /root/.nvm/versions/node/v18.16.0/bin/node,白纸黑字。node 明明就装在这台机器上,明明就在那儿,我自己手敲随时能用——可同一台机器上的 cron,执行同一个脚本,却咬定"找不到 node 这个命令"。同一台机器、同一个 node、同一行命令,凭什么"我"能用,"cron"就不能用?难道"一个命令装没装在这台机器上",还要分【是谁在问】?我盯着那行报错,第一次开始怀疑:我一直以为的"node 装好了"——这个"装好了",到底是对【谁】成立的?这件事逼着我把 command not found 的真正含义、PATH、登录/非登录 shell、.bashrc 与 .bash_profile、cron 的环境这一整套彻底理清了。本文复盘这次实战。

问题背景

环境:CentOS 7,node 用 nvm 装在 /root/.nvm/...
事故现象:
- 手动执行 deploy.sh 里的命令,node 跑得好好的
- ★ 把 deploy.sh 挂进 crontab,自动跑就报:
  deploy.sh: line 8: node: command not found

现场排查:
# 1. 我自己手敲 —— node 完全正常
$ node -v
v18.16.0                                       # ★ 能跑
$ which node
/root/.nvm/versions/node/v18.16.0/bin/node     # ★ 在这儿

# 2. ★ 可 cron 跑同一个脚本,报找不到 node
$ tail /var/log/deploy.log
deploy.sh: line 8: node: command not found     # ★ 找不到

# 3. ★ 关键:看"我"的 PATH 和"cron"的 PATH,差在哪
$ echo $PATH
/root/.nvm/versions/node/v18.16.0/bin:/usr/local/bin:/usr/bin:/bin
# ★ 我的 PATH 里,【有】那个 .nvm 的 bin 目录。

# 4. ★ 让 cron 打印它自己的 PATH —— 在 crontab 里临时加一行
* * * * * echo "cron PATH=$PATH" >> /tmp/cronpath.log
$ cat /tmp/cronpath.log
cron PATH=/usr/bin:/bin                        # ★★ 就这俩!
# ★ cron 的 PATH 里,【根本没有】.nvm 那个 bin 目录。

# 5. 看 node 的目录,到底是怎么进我 PATH 的
$ grep -rn 'nvm' ~/.bashrc ~/.bash_profile
/root/.bashrc:10: export NVM_DIR="$HOME/.nvm"
/root/.bashrc:11: [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"
# ★ 把 node 加进 PATH 的那段代码,在 ~/.bashrc 里。

根因(后来想清楚的):
1. ★ shell 执行一条命令(如 node),不会满硬盘找。
   它只在【环境变量 PATH 列出的那几个目录】里找。
2. ★ 我的交互式 shell,PATH 里有 .nvm 的 bin —— 因为
   登录时读了 ~/.bashrc,nvm 那段代码把它加了进去。
3. ★ 但 cron 执行任务时,启动的是一个【全新的、
   极简的 shell】。它【不读】我的 ~/.bashrc。
4. ★ 所以 cron 的 PATH 只有最朴素的 /usr/bin:/bin。
   .nvm 那个目录,从来没进过 cron 的 PATH。
5. ★ 于是:同一个 node,我找得到(我的 PATH 覆盖
   了它),cron 找不到(cron 的 PATH 没覆盖它)。
6. 真相:"node 装好了"这件事,从来不是对"整台
   机器"成立的,而是对"PATH 里包含它的那个环境"
   成立。环境不同,PATH 不同,"装没装好"就不同。
不是 node 没装,是 cron 那个环境的 PATH,从来
没把 node 所在的目录算进去。

修复 1:command not found——shell 只在 PATH 列的目录里找命令

# === ★ 先搞懂 shell 是怎么"找到"一条命令的 ===

# === ★ 你敲 node,shell 做了什么 ===
# 你在终端敲 node 回车。node 不是 shell 内置的东西,
#   它是一个【可执行文件】,躺在硬盘某个目录里。
# ★ shell 要执行它,得先【找到】那个文件。问题来了:
#   硬盘上目录千千万,shell 去哪找?

# === ★ 反直觉的事实:shell 不会"满硬盘找" ===
# 我一直以为,shell 找命令,会像 find 那样把整个
#   硬盘翻一遍。★ 错。那样太慢了。
# ★ shell 找命令,只查一个地方:环境变量 PATH。
#   PATH 里列着【一串目录】,shell 就【只】在这
#   几个目录里,按顺序找有没有叫 node 的可执行文件。
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/root/.nvm/.../bin
# ★ PATH 是一串目录,用【冒号】分隔。

# === ★ command not found 的准确含义 ===
# shell 把 PATH 里每个目录都翻了一遍,都没找到一个
#   叫 node 的可执行文件 —— 这时它就报:
#   bash: node: command not found
# ★ 注意,它【没有】说"这台机器上没有 node"。
#   它说的是:"在我被告知要找的那几个目录里
#   (PATH),没有 node。"
# ★ 这两句话天差地别。node 完全可能就装在硬盘上,
#   只是它所在的目录,不在 PATH 这张清单里 ——
#   于是 shell"看都没去看那个目录"。

# === ★ 一个类比:PATH 是 shell 的"通讯录" ===
# 你想联系一个人。你不会满世界喊,你会翻通讯录。
#   通讯录里有他 -> 你找得到;通讯录里没有他 ->
#   你"联系不上"他 —— 哪怕他本人就站在隔壁。
# ★ PATH 就是 shell 找命令的通讯录。command not
#   found = "我的通讯录里没这个人",不等于"这个
#   人不存在"。

# === ★ 验证:命令到底在不在硬盘上 ===
# 报 command not found 时,先分清两件事:
# (A) 这命令到底装没装在硬盘上?—— 用 find 全盘找:
$ find / -name node -type f 2>/dev/null
/root/.nvm/versions/node/v18.16.0/bin/node     # ★ 装了!在这
# (B) 它所在的目录,在不在 PATH 里?
$ echo $PATH | tr ':' '\n' | grep nvm
（空)                                          # ★ 不在 PATH
# ★ (A)有、(B)没有 —— 这就是典型的"装了、但 shell
#   找不到":不是没装,是 PATH 没覆盖它。

# === 认知 ===
# ★ shell 找命令,只在环境变量 PATH 列出的目录里
#   找,绝不满硬盘搜。command not found 的真正含义
#   是"PATH 列的目录里没有它",不等于"这台机器上
#   没装它"。排查时先用 find 确认装没装,再看它
#   的目录在不在 PATH。

修复 2:which、type、command -v——查清一条命令的来历

# === ★ 排查命令问题,先学会"查命令的户口" ===

# === ★ which:这命令,实际会用 PATH 里的哪一个 ===
$ which node
/root/.nvm/versions/node/v18.16.0/bin/node
# ★ which 在你当前的 PATH 里,从前往后找,告诉你
#   shell 实际会执行【哪个路径】下的 node。
# ★ 注意:which 用的是【它自己进程】的 PATH。在
#   交互式 shell 里 which 到,不代表 cron 里也能 ——
#   因为 PATH 不同。

# === ★ type:比 which 更全 —— 它还认得别名、函数 ===
$ type node
node is /root/.nvm/.../bin/node
$ type ll
ll is aliased to `ls -l --color=auto'          # ★ ll 是个别名
$ type cd
cd is a shell builtin                          # ★ cd 是内置命令
# ★ type 能告诉你:这个名字,到底是【外部命令】、
#   【别名 alias】、【shell 函数】,还是【内置命令】。
# ★ 排查"为什么手敲能用、脚本里不行",type 很关键 ——
#   因为别名和函数,只在交互式 shell 里有,脚本里
#   通常【没有】。手敲用的可能是个别名,脚本里那个
#   别名不存在,就 command not found。

# === ★ command -v:脚本里最该用的那个 ===
$ command -v node
/root/.nvm/.../bin/node
$ command -v node >/dev/null 2>&1 && echo "有 node" || echo "没有 node"
# ★ command -v 是【POSIX 标准】的,各种 shell 都认,
#   适合写在脚本里做"这个命令在不在"的判断。
# ★ 别在脚本里用 which 做判断 —— which 不是所有
#   系统都有、行为也不统一。command -v 才是正解。

# === ★ 一条命令可能有"好几个",PATH 顺序决定用哪个 ===
$ type -a python
python is /usr/local/bin/python                # ★ 第一个 —— 实际用这个
python is /usr/bin/python                      # ★ 还有一个
# ★ type -a 列出 PATH 里【所有】同名命令。shell
#   实际执行的,是 PATH 里【最靠前】那个目录里的。
# ★ 这解释了一类怪事:"我装了新版,怎么跑的还是
#   老版?"—— 老版所在目录,在 PATH 里排得更靠前。

# === ★ 看一个命令"是不是真能执行" ===
$ ls -l /root/.nvm/.../bin/node
-rwxr-xr-x 1 root root ... node                # ★ 有 x 执行位
# ★ 就算命令在 PATH 里,如果它没有【执行权限(x)】,
#   照样跑不了(报 Permission denied,不是 not found)。
#   两种报错要分清。

# === 认知 ===
# ★ 查命令来历三件套:which 看实际用 PATH 里哪个,
#   type 看它是命令/别名/函数/内置(排查"手敲能用
#   脚本不行"必用),command -v 是脚本里判断命令
#   存在的标准做法。type -a 看同名命令有几个 ——
#   PATH 里靠前的那个胜出。

修复 3:登录 / 非登录、交互 / 非交互——shell 读哪个配置文件

# === ★ 本文的核心:不同的 shell,读不同的配置文件 ===

# === ★ 一个关键问题:.nvm 那段代码,谁去执行它 ===
# node 能进我的 PATH,是因为 ~/.bashrc 里有一段
#   nvm 代码,登录时被执行了。
# ★ 但 ~/.bashrc 这个文件,【不是每次都会被读】的。
#   读不读它,取决于启动的是【什么类型的 shell】。

# === ★ shell 分两个维度,共四种 ===
# 维度一:登录 shell(login) vs 非登录(non-login)
#  - ★ 登录 shell:你 SSH 连上服务器、或在控制台
#    输账号密码登录 —— 那一刻启动的 shell。
#  - ★ 非登录 shell:已经登录后,你再敲 bash 开个
#    子 shell、或运行一个脚本 —— 这些是非登录的。
# 维度二:交互式(interactive) vs 非交互式
#  - ★ 交互式:有提示符、等你敲命令的那种。
#  - ★ 非交互式:执行一个脚本文件,跑完就退 ——
#    没人跟它互动。

# === ★ 不同类型的 shell,读不同的文件(bash)===
# ★ 登录 shell 启动时读:
#     /etc/profile  ->  然后 ~/.bash_profile
#     (~/.bash_profile 里通常又会主动去 source
#      ~/.bashrc)
# ★ 非登录的交互式 shell 启动时读:
#     /etc/bashrc  ->  ~/.bashrc
#     (★ 它【不读】~/.bash_profile)
# ★ 非交互式 shell(执行脚本):
#     ★ 上面这些,基本【一个都不读】!
#     它只认 $BASH_ENV 指向的文件(通常没设)。

# === ★ 一张表,记住谁读谁 ===
# 场景                      读 .bash_profile  读 .bashrc
# SSH 登录(交互)              ★ 读           读(被profile带)
# 登录后敲 bash(交互非登录)    不读             ★ 读
# 跑一个 .sh 脚本(非交互)      不读             ★ 不读!
# cron 执行任务(非交互)        不读             ★ 不读!
# ★ 重点看最后两行:脚本和 cron,【两个配置文件
#   都不读】。所以 ~/.bashrc 里的 PATH 修改,对
#   它们【完全无效】。

# === ★ 这就解释了本文的怪事 ===
# - 我 SSH 登录 -> 是登录交互 shell -> 读了 ~/.bashrc
#   -> nvm 代码执行了 -> node 进了我的 PATH。✓
# - cron 跑 deploy.sh -> 是非交互 shell -> ★ 不读
#   ~/.bashrc -> nvm 代码【从没执行】-> node 不在
#   cron 的 PATH。✗
# ★ 同一台机器,我和 cron,根本就是两个【环境
#   不同】的 shell。

# === ★ .bash_profile 与 .bashrc 该放什么 ===
# ★ ~/.bash_profile:放"登录时做一次就够"的东西 ——
#   比如设 PATH、设环境变量。
# ★ ~/.bashrc:放"每开一个交互 shell 都要有"的
#   东西 —— 比如 alias、函数、提示符 PS1。
# ★ 常见的正确做法:把 PATH 这类环境变量,放进
#   ~/.bash_profile;~/.bashrc 开头再 source 一下
#   ~/.bash_profile(或反过来),保证两种 shell
#   都拿得到。很多发行版默认就这么配。

# === 认知 ===
# ★ bash 分登录/非登录、交互/非交互。登录 shell
#   读 ~/.bash_profile,非登录交互 shell 读 ~/.bashrc,
#   而【执行脚本和 cron 这种非交互 shell,两个都
#   不读】。所以把 PATH 改在 ~/.bashrc 里,脚本和
#   cron 根本看不到 —— 这是"手敲能跑、脚本不行"
#   最常见的根源。

修复 4:cron 与 sudo 的 PATH——它们是另一套环境

# === ★ cron 和 sudo,各有自己一套"干净"的环境 ===

# === ★ cron 的环境有多"穷" ===
# cron 执行任务时,不继承你登录 shell 的任何环境。
#   它给任务一个【极简的、近乎空白】的环境:
#  - PATH 通常只有  /usr/bin:/bin
#  - HOME、SHELL、LOGNAME 有,其它基本啥也没有
#  - ★ 你 ~/.bashrc 里 export 的一切,cron 一概不知。
# ★ 所以"手敲一切正常、放进 cron 就各种找不到",
#   是 cron 任务最高频的坑,几乎都是环境/PATH 问题。

# === ★ cron 任务里解决 PATH,三个办法 ===
# 办法 1:★ 在 crontab 文件顶部,直接定义 PATH:
$ crontab -e
PATH=/root/.nvm/versions/node/v18.16.0/bin:/usr/local/bin:/usr/bin:/bin
0 2 * * * /opt/deploy.sh
# ★ crontab 文件里可以写环境变量,写在任务行之前,
#   对下面所有任务生效。

# 办法 2:★ 在脚本里,用【绝对路径】调用命令:
#   把 deploy.sh 里的  node build.js
#   改成           /root/.nvm/.../bin/node build.js
# ★ 绝对路径根本不经过 PATH 查找,最稳,但写死了。

# 办法 3:★ 在脚本开头,自己把 PATH 补全:
$ head -3 /opt/deploy.sh
#!/bin/bash
export PATH="/root/.nvm/versions/node/v18.16.0/bin:$PATH"
# ★ 或者,如果环境复杂,脚本开头主动 source 一下
#   需要的配置: source /root/.bash_profile
#   (但要确保该文件能被非交互 shell 安全 source)

# === ★ sudo 也有自己的 PATH:secure_path ===
# 你 sudo 跑一个命令时,用的【不是】你自己的 PATH。
#   出于安全,sudo 会重置 PATH 成一个固定的值:
$ sudo grep secure_path /etc/sudoers
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin
# ★ 这就是 sudo 命令时的 PATH。它通常【不包含】
#   /usr/local/bin、更不会有 .nvm 这种目录。
# ★ 所以"我能跑 node,sudo node 却 command not
#   found" —— 因为 sudo 用的是 secure_path,那里
#   面没有 node。
$ sudo node -v
sudo: node: command not found                  # ★ 典型现象
# 解决:sudo 时用绝对路径,或在 sudoers 的
#   secure_path 里补上需要的目录(visudo 改)。

# === ★ systemd service 同理 ===
# systemd 拉起的服务,环境也是干净的、PATH 极简。
#   service 文件里要用 Environment= 或
#   ExecStart 写绝对路径,别指望它有你的 PATH。

# === ★ 怎么看一个"环境"里到底有什么 ===
# 想知道 cron / 某脚本 跑起来时环境长啥样,最直接:
#   让它执行一次 env,把结果存下来看:
* * * * * env > /tmp/cron_env.log               # cron 的环境
$ cat /tmp/cron_env.log
# ★ 这一招能让"看不见的环境"现形 —— 排查环境类
#   问题,屡试不爽。

# === 认知 ===
# ★ cron、sudo、systemd 各自有一套干净、极简的
#   环境,PATH 都很短,不继承你登录 shell 的环境。
#   "手敲能跑、它们跑不了",几乎总是 PATH 问题。
#   解法:在 crontab 顶部定义 PATH、脚本里用绝对
#   路径、或 sudo 的 secure_path 里补目录。

修复 5:hash 缓存——命令明明移走了,shell 还记得旧位置

# === ★ 还有一类怪事:和 PATH 无关,是 shell 的"记性" ===

# === ★ 现象:命令移动了,shell 却还报旧路径 ===
# 你把一个命令从 /usr/local/bin 移到了别处,然后:
$ mytool
bash: /usr/local/bin/mytool: No such file or directory
# ★ 注意!报错带着【完整旧路径】,而且说的是
#   "No such file",不是 "command not found"。
# ★ 这说明:shell 没去 PATH 重新找,它【凭记忆】
#   直接奔老地方去了 —— 扑了个空。

# === ★ shell 会"记住"命令的位置:hash 表 ===
# 每次 shell 在 PATH 里成功找到一个命令,它会把
#   "命令名 -> 完整路径"这个结果,★【缓存】下来,
#   存进一张叫 hash 的表里。
# ★ 目的:下次再敲同一个命令,直接查缓存,不用
#   再把 PATH 一个个目录翻一遍 —— 为了快。
$ hash
hits    command
   5    /usr/local/bin/mytool                   # ★ 缓存着旧路径
   12   /usr/bin/ls
# ★ hash 命令(不带参数)就能看当前缓存了哪些。

# === ★ 缓存带来的两种"灵异事件" ===
# 事件 A:命令移走/删了,shell 还按旧路径找 ->
#   报 "No such file or directory"(带旧全路径)。
# 事件 B:★ 更诡异的 —— 命令明明已经删了,你敲它
#   居然还能"跑"(其实是缓存的路径碰巧还在),或
#   你装了新版到新位置,敲命令跑的还是缓存里的旧版。
# ★ 共同点:shell 用的是【过期的记忆】,不是
#   PATH 的【当前现实】。

# === ★ 解药:hash -r,清空这张缓存表 ===
$ hash -r
# ★ hash -r 把缓存全部清空。之后再敲命令,shell
#   会【重新】老老实实去 PATH 里找一遍。
$ hash -d mytool        # 或只清掉某一个命令的缓存
# ★ 命令"装了新版却不生效""移动后报旧路径",
#   先 hash -r 试试 —— 十有八九立刻就好。

# === ★ 怎么区分"PATH 问题"还是"hash 缓存问题" ===
# 看报错的措辞:
#  - ★ command not found            -> PATH 问题
#    (PATH 里压根没有这个命令)。
#  - ★ /旧/全/路径: No such file ... -> hash 缓存
#    问题(缓存了一个已失效的路径)。
# ★ 报错带不带"完整路径",是区分这两类问题的
#   关键线索。

# === ★ 注:hash 缓存是"每个 shell 各自一份" ===
# hash 表是当前这个 shell 进程私有的。你开一个新
#   终端,新 shell 的 hash 是空的,自然不受旧缓存
#   影响 —— 这也是"重开一个终端就好了"的原理。

# === 认知 ===
# ★ shell 会把"命令 -> 路径"缓存进 hash 表加速
#   查找。命令移动/换新版后,旧缓存会让 shell 按
#   过期路径找,报"/全路径: No such file"或跑了
#   旧版。hash -r 清空缓存即可。报错带不带完整
#   路径,是判断 PATH 问题还是 hash 问题的关键。

修复 6:命令找不到排查纪律

# === 这次事故暴露的认知盲区,定几条纪律 ===

# === 1. ★ shell 只在 PATH 列出的目录里找命令,绝不满硬盘搜 ===

# === 2. ★ command not found = "PATH 里没有它",不等于"机器上没装它" ===

# === 3. 报 command not found 先 find 确认装没装,再看它的目录在不在 PATH ===
$ find / -name 命令名 -type f 2>/dev/null

# === 4. ★ 查命令来历:which 看实际路径,type 看是否别名/函数,command -v 给脚本用 ===

# === 5. ★ 脚本和 cron 是非交互 shell,不读 ~/.bashrc 也不读 ~/.bash_profile ===

# === 6. ★ PATH 改在 ~/.bashrc 里,脚本和 cron 看不到 —— 这是"手敲能跑脚本不行"的头号原因 ===

# === 7. ★ cron 的 PATH 极简(/usr/bin:/bin),在 crontab 顶部显式定义 PATH ===
PATH=/需要的目录:/usr/local/bin:/usr/bin:/bin

# === 8. ★ sudo 用的是 secure_path 不是你的 PATH,sudo 找不到命令查这里 ===

# === 9. 脚本里调关键命令,用绝对路径最稳;判断命令是否存在用 command -v ===

# === 10. 排查"command not found"的步骤链 ===
$ type 命令                          # ① 是别名/函数/命令?
$ which 命令                         # ② 当前 PATH 里在哪
$ echo $PATH                         # ③ 我的 PATH 有哪些目录
$ find / -name 命令 2>/dev/null       # ④ 它到底装在哪
$ env > /tmp/x.log（在出问题的环境里) # ⑤ 那个环境的 PATH 长啥样
# 报错带完整旧路径 -> 是 hash 缓存,hash -r 即可。
# 按这个顺序,"命令明明在却找不到"基本能定位、能根治。

命令速查

需求                        命令
=============================================================
看当前 PATH                 echo $PATH
PATH 按目录逐行看            echo $PATH | tr ':' '\n'
看命令实际用哪个路径        which 命令
看命令是别名/函数/内置      type 命令
看同名命令有几个            type -a 命令
脚本里判断命令是否存在      command -v 命令 >/dev/null
全盘找一个命令              find / -name 命令 2>/dev/null
看 shell 缓存了哪些命令     hash
清空命令位置缓存            hash -r
看某环境的全部变量          env
看 sudo 的 PATH             sudo grep secure_path /etc/sudoers
crontab 里定义 PATH         在文件顶部写 PATH=...

口诀:command not found 是 PATH 里没有不是机器上没装,脚本和 cron 不读 bashrc
      PATH 改 bashrc 脚本看不到,cron 在 crontab 顶部定义 PATH,关键命令用绝对路径

避坑清单

1. shell 执行命令只在环境变量 PATH 列出的那几个目录里找,绝不会像 find 那样满硬盘搜索
2. command not found 的真正含义是 PATH 列的目录里没有它,完全不等于这台机器上没装它
3. 报 command not found 先 find 全盘确认装没装,再看它所在目录在不在 PATH 里这是两件事
4. which 看命令实际路径,type 看它是命令还是别名还是函数,脚本里判断存在用 command -v
5. 脚本和 cron 跑的是非交互 shell,它既不读 ~/.bashrc 也不读 ~/.bash_profile 配置文件
6. 把 PATH 修改写在 ~/.bashrc 里,脚本和 cron 根本看不到,这是手敲能跑脚本报错的头号原因
7. cron 给任务的环境极简 PATH 通常只有 /usr/bin:/bin,要在 crontab 文件顶部显式定义 PATH
8. sudo 执行命令用的是 sudoers 里的 secure_path 不是你自己的 PATH,sudo 找不到命令查这里
9. 脚本里调用关键命令用绝对路径最稳妥,因为绝对路径根本不经过 PATH 查找不受环境影响
10. 报错带完整旧路径说 No such file 是 hash 缓存过期,hash -r 清空缓存让 shell 重新查找

总结

这次"我能用、cron 不能用"的事故,纠正了我一个关于"安装"的、几乎从未被审视过的执念。在我过去的脑子里,"在一台机器上装好一个程序",是一个【全局的、对所有人一视同仁的】事实。就像往一个房间里搬了一张桌子——桌子搬进来了,那么屋里的【任何人】,转过身都能看见它、用上它。"装好了"对我而言,是一个盖在【整台机器】上的图章:盖下去,这台机器从此就"有"了这个程序,无论谁来问,答案都是"有"。可这次,同一台机器,我问它"有没有 node",它说"有";cron 问它同样的问题,它说"没有"。我守着的那个"全局事实",当场就裂开了。现场逼着我承认:"装好了"从来不是盖在机器上的图章,它更像是写在【某一个特定环境的通讯录】里的一行字。我能找到 node,不是因为"机器装了 node",而是因为"【我这个 shell 的 PATH】里,登记了 node 所在的那个目录"。而 cron 找不到,也不是因为"机器没装",而是"【cron 那个 shell 的 PATH】里,从来没登记过那个目录"。同一个 node,静静地躺在硬盘的同一个位置,一个字节都没变。变的,是【来问的人,各自带着一本不同的通讯录】。我一直以为只有一本通讯录,一本属于"这台机器"的、唯一的、权威的通讯录;可真相是,每一个 shell、每一个 cron 任务、每一次 sudo,都揣着【自己那一本】,而且这些本子,内容很可能天差地别。复盘到根上我才明白,我混淆了"一个东西存在"和"一个东西能被某人触及"。node 这个文件,客观地"存在"于硬盘上——这一点谁都不否认。但"能不能用上它",从来不是它单方面的属性,而取决于【来找它的那个环境,有没有一条路通向它】。存在,是它的事;可达,是环境的事。我过去把这两件事焊死成了一件,以为"它在"就等于"谁都能用它"。这次最大的收获,是我学会了在说"我已经配好了""我已经装好了""我已经设置好了"之前,追问一句:配好了——是【在哪个环境里】配好了?那个真正要用它的环境,和我此刻配置它的环境,是【同一个】吗?我在自己的登录终端里把一切都铺得妥妥帖帖,可那个深夜默默执行任务的 cron,活在另一个我从没去探望过的、空荡荡的环境里;我以亲历者的身份验证一切正常,可那个以 sudo 身份、以服务身份、以另一个用户身份运行的它,看到的是另一片天地。所以下一次,当某样东西"我这儿明明好好的、换个地方就用不了"时,我不会再举着我那本通讯录,坚称"它就是配好了的"。我会走到那个真正出问题的环境里去,蹲下来,翻开【它】手里的那本通讯录,一行一行地看:它,到底能不能从这里,找到一条路,走到那个东西面前。因为让一个东西"存在"是不够的;你得让它,出现在那个真正需要它的环境的通讯录里。

—— 别看了 · 2026