权限上的本质区别#

这也是为什么日常开发都应该待在 ~ 及其子目录下——那是你安全的地盘;/usr、/System 这种是系统地基,乱动容易搬起石头砸自己的脚。

常见踩坑#

1. cd 不带参数 = cd ~——很多人不知道空 cd 就是回家,其实是最常用的抄近路。
2. ~ 只在 shell 里生效,加引号会失效:echo ~ 展开成路径,echo "~" 原样输出波浪线。写进脚本变量或字符串时更保险的写法是 $HOME,引号里也能正常展开。
3. ~username 可以跳到别人的家目录(前提是权限允许)。
4. macOS Finder 侧边栏的”Home”图标 ≠ 系统层面的 /——那个小房子指的是 ~,真正的文件系统根是 Macintosh HD 那一层。
5. 在 / 下清理东西,和在 ~ 下清理东西,风险不是一个量级——尤其带上 sudo 之后,出错的影响面从”搞乱自己的文件”变成”影响整个系统”。

真正容易踩坑的地方:执行命令 vs 引用路径,规则不一样#

同样一个 ./,在两种场景下”要不要写”的规则完全不同(原因要等下一节 $PATH 才能说透,这里先记住结论):

• 执行一个命令(比如 script.sh):必须写 ./,不然报错 command not found。

  1
  script.sh      # ❌ command not found
  2
  ./script.sh    # ✅ 正确
  

• 引用一个路径作为参数(比如 cat subfolder/file.txt):写不写 ./ 前缀都行。

  1
  cat subfolder/file.txt     # ✅
  2
  cat ./subfolder/file.txt   # ✅ 一模一样
  

一句话记住:. 不是门,是”你现在脚下这块地”的名字,从没让你移动到任何新地方。

其他几个常见的连带踩坑#

• rm -rf ./* 和 rm -rf ./ 天差地别,操作前一定 pwd 确认自己在哪。
• cd ..data 会被当成一个叫 ..data 的目录名报错,拼接时别漏了斜杠。
• cp -r folder1/. folder2 利用的正是”. = 目录内容本身”这个含义,用来避免多一层嵌套目录。
• find -name "*.csv" 有些系统上会报错,记得写成 find . -name "*.csv" 明确从当前目录开始。
• Git 里 HEAD~1..HEAD 的 .. 是”两个提交之间”的语法糖,和路径完全无关——同一个符号在不同工具里语义不同,操作前留个心眼。

这些目录(挂在”一、地图”里的 / 下面)各自装的是什么#

拿 grep 举个例子:ls /bin 是找不到 grep 的,它躺在 /usr/bin 里。这不是巧合,是这几个目录各自的定位不同:

• /bin——只放系统启动、单用户/救援模式下必须要有的极少数命令:sh、cat、cp、mv、rm、ls、kill、pwd、date 这类。老 Unix 系统里 /usr 有时候挂载在另一个硬盘分区上,系统刚启动、/usr 还没挂载好时,手头能用的只有 /bin 和 /sbin,所以这里必须精简到”哪怕系统半残也能修”的程度(在我机器上只有 37 个文件)。
• /usr/bin——放日常真正干活用的完整工具集:grep、awk、sed、find、curl、python3 全在这。这些不是”救命必需品”,系统正常挂载完 /usr 之后才需要,所以数量可以很大(我机器上快 1000 个)。
• /usr/local/bin——放不属于操作系统自身、由你或第三方装的软件,专门和系统维护的 /usr/bin 分开,避免互相污染。平时用 Homebrew 装的东西(brew install xxx)十有八九落在这(Intel Mac 是 /usr/local/bin,Apple Silicon Mac 默认是 /opt/homebrew/bin)。

这个”/usr 曾是独立分区”的历史原因,在很多现代 Linux 发行版里已经名存实亡(不少发行版直接把 /bin 做成指向 /usr/bin 的软链接,两者合并了)。但 macOS 仍然保留两者物理分离,而且 /bin、/usr/bin 这些系统目录还被 SIP(System Integrity Protection) 保护着——哪怕是 root,默认也改不了里面的文件,苹果把这层锁死了,想自己装软件只能老老实实走 /usr/local。

顺序不是随便排的:实测一遍#

回看 $PATH 的顺序:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin——/usr/local/bin 排在最前面,意味着如果你自己装的软件和系统自带的重名,你装的那个优先生效。用两个同名脚本实测一下,谁排前面谁被执行:

1
# dirA/mytool 和 dirB/mytool 内容不同,都叫 mytool
2

3
$ PATH="dirA:dirB:$PATH" mytool
4
我是 dirA 里的 mytool     # dirA 排前面,执行的是它
5

6
$ PATH="dirB:dirA:$PATH" mytool
7
我是 dirB 里的 mytool     # 换成 dirB 排前面,执行的变成它

同一个命令名,同一个 $PATH,唯一变量是谁排在前面,结果就完全不同——shell 找到第一个匹配就停,不会继续找,更不会”两个都执行”或者报错说重名。这也是为什么 Homebrew 装的 python3、node、git 版本能够”覆盖”系统自带的同名版本:不是真的覆盖或删除了系统版本(/usr/bin 里的原版还在,受 SIP 保护动不了),只是 /usr/local/bin(或 /opt/homebrew/bin)排在 $PATH 更前面,shell 优先找到了它。

which:帮你重演一遍这次搜索#

1
which echo

which 不执行程序,只是模拟一遍 shell 会做的查找过程,告诉你”如果现在敲这个命令,实际执行的是哪个文件”。排查”为什么跑的是这个版本""这个命令到底装在哪”时非常好用。

回到”称呼”这一节:直接给路径 = 绕过整个 $PATH 搜索#

1
/bin/echo $PATH

这里直接写了完整路径,shell 不需要去 $PATH 翻,因为你已经明确指名道姓。上一节的 ./script.sh 是同一个原理——./ 就是在说”文件就在当前目录,不用去 $PATH 里搜”。

深层原因:为什么当前目录不在 $PATH 默认搜索范围里#

这倒不是说”当前目录容易有坏文件”这么简单,根子在于权限归属不对称:

当前目录可能是你解压的压缩包、别人共享的网盘文件夹、git clone 下来的陌生仓库、多用户系统里大家都能写的共享目录——这些地方的内容所有权不一定在你手里。

经典攻击场景:攻击者在共享目录里放一个名字就叫 ls 的可执行文件,内容是先偷偷做点坏事、再老实调用真正的 /bin/ls 掩人耳目。如果你的 $PATH 把 . 排在前面,你在这个目录下敲 ls(不需要写 ./!)就会先执行攻击者的版本,而且表面上看起来完全正常。这就是安全圈里的经典漏洞类型 untrusted search path(CWE-426)。

所以老一辈 Unix 安全指南反复强调一句话:永远不要把 . 加进 $PATH,哪怕加在最后面也有风险窗口。

常见的几个文件,以及它们何时被读取#

zsh(macOS 默认 shell)和 bash 各自有一套类似但不完全相同的启动文件:

日常你手动编辑、加 alias、改 $PATH 的,基本都是 .zshrc(zsh)或 .bashrc(bash)——因为你关心的场景通常就是”我开个终端窗口,想让它是我要的样子”。

关键认知:配置文件经常只是个”入口”,真正的代码藏在它 source 的其他文件里#

which grep 有时会显示一个 alias,但直接翻 .zshrc 却找不到 alias grep=。原因是 .zshrc 里可能就一行:

1
source $ZSH/oh-my-zsh.sh

这一行会自动把 ~/.oh-my-zsh/lib/*.zsh 下所有核心库文件都 source 一遍,其中 lib/grep.zsh 才是真正定义这个 alias 的地方。也就是说,.zshrc 本身只有几十行,但它间接拉入的代码可能有几千行——插件管理器(oh-my-zsh、prezto、zinit)、Homebrew 的 shellenv、conda 的 profile.d/conda.sh,都是通过这种”一行 source,背后一大坨”的方式生效的。

排查 shell 行为异常时,思路应该是:

1. 先看 .zshrc/.bashrc 里有没有直接写着的答案
2. 如果没有,搜它 source 了哪些文件(grep -nE "^\s*(source|\.)\s" ~/.zshrc)
3. 顺着这条线一层层往下挖,直到找到真正定义行为的那一行

真实例子:装 miniconda 那次,到底发生了什么#

很多人第一次真正碰 .zshrc,不是自己手动写的,而是装某个工具的时候它自己写进去的——miniconda 就是典型。装完跑一次 conda init,.zshrc 末尾会自动多出这样一段:

1
# >>> conda initialize >>>
2
# !! Contents within this block are managed by 'conda init' !!
3
__conda_setup="$('/Users/sean/miniconda3/bin/conda' 'shell.zsh' 'hook' 2> /dev/null)"
4
if [ $? -eq 0 ]; then
5
    eval "$__conda_setup"
6
else
7
    if [ -f "/Users/sean/miniconda3/etc/profile.d/conda.sh" ]; then
8
        . "/Users/sean/miniconda3/etc/profile.d/conda.sh"
9
    else
10
        export PATH="/Users/sean/miniconda3/bin:$PATH"
11
    fi
12
fi
13
unset __conda_setup
14
# <<< conda initialize <<<

拆开看,这段代码在干嘛:

• >>> conda initialize >>> / <<< conda initialize <<< 这两行注释,是个约定俗成的”托管区域”标记——意思是”这一块是工具自动生成/更新的,你最好别手动改,以后重新跑 conda init 会整块替换掉”。不少工具(nvm、pyenv、rbenv 等)都用类似手法在你的配置文件里划一块自己的地盘。
• 真正决定”优先用 conda 的 python”的,是最后那句 fallback:export PATH="/Users/sean/miniconda3/bin:$PATH"。注意它是把 miniconda 的 bin 目录塞到 $PATH 最前面,不是加到最后面——这正好是我们在”三、查找机制”里用 mytool 实测过的那条规则:谁排在 $PATH 前面,谁就被优先找到。所以激活 conda 之后敲 python,即使 /usr/bin/python3 依然存在,shell 也会先找到 miniconda 目录下的那份,不需要真的卸载或覆盖系统自带的 Python。
• 上面那段 __conda_setup/eval 的写法比直接 export PATH=... 更”高级”:它先尝试调用 conda shell.zsh hook 动态生成一整套初始化代码(不只是改 $PATH,还包括 conda activate 这种命令能正常工作所需的 shell 函数),用 eval 执行;只有这个动态生成失败时,才退回到”直接改 $PATH”这种最朴素的兜底方案。

这也是为什么很多人会有种”conda 会偷偷改我的配置文件”的感觉——它确实会,而且是通过在 .zshrc 里插入这种自维护的代码块来实现”每次开终端都自动把 conda 环境准备好”。理解了 $PATH 前插 vs 后插的区别,这段乍看复杂的代码其实就是”把自己塞到队伍最前面”这一件事。

常见踩坑#

1. 改了配置,新开的终端却没生效——因为改动只影响之后新启动的 shell,当前这个终端窗口读配置文件的那一刻早就过去了。想让当前窗口立刻生效,得手动 source ~/.zshrc 重新执行一遍。
2. 改错了文件——你用的是 zsh,却在改 .bashrc,自然什么都不会发生。不确定自己用的是哪个 shell,echo $SHELL 或 echo $0 能看出来。
3. $PATH 越改越长、越改越乱——很多工具(Homebrew、nvm、conda、pyenv)安装时都会自作主张往 .zshrc 追加一段 export PATH=...,装的工具一多,.zshrc 底部一大坨,顺序混乱、甚至出现重复路径。定期 echo $PATH 看看有没有明显冗余,是个好习惯。
4. .zshenv 里不要放太”重”的东西——因为它连非交互式场景(比如脚本、cron、某些 GUI 程序启动的子 shell)都会读,放个慢启动的东西(比如笨重的 conda 初始化)会拖慢一切调用 shell 的地方,不只是你手动开的终端。