命令行里敲得最多的命令cd排第二没人敢排第一。可偏偏就是这条几乎每天都要摸一遍的命令三种写法——cd ..、cd /、cd ~——在很多人的脑子里是糊成一片的。我在带人做运维交付的时候见过不少脚本跑着跑着把文件写到了意料之外的目录回头一查问题就出在这三个写法被混用上。它们看起来都是往回走或找个地方待着实际含义、作用范围、失效条件完全不是一回事。这篇东西我想把它彻底讲透从路径系统的底层逻辑讲起拆清三种写法各自的行为边界再补上 shell 在背后替你做的那些隐形动作最后把我这些年踩过的坑整理成可直接对照的排查表。不管你是刚接触命令行、分不清..和/的新手还是写了几年脚本、但从没认真想过cd ~为什么会失效的老手应该都能从这里捞到点东西。1. 先把三个符号的底子钉死路径系统到底怎么读1.1 绝对路径与相对路径是所有混乱的源头在动手拆cd之前得先把路径的两套坐标系理清楚不然讲什么都是空中楼阁。文件系统是一棵倒挂的树最顶上那个节点叫根目录写作一个斜杠/。绝对路径是从根目录出发、一路写到底的完整地址比如/var/log/app它的含义是唯一的跟你现在站在哪儿没有任何关系。相对路径则相反它是相对于你当前所在位置来描述的比如logs/app意思是从我现在站的这个地方往下走两层。同一个相对路径站在不同的目录里执行指向的目标完全不同。关键在于相对路径的解析必须有一个参照点这个参照点就是进程的当前工作目录current working directory简称 cwd。每个进程都有且只有一个 cwd它是进程属性的一部分不是某个文件的属性。你用pwd命令打出来的那一行就是在问 shell 进程你的 cwd 是什么。这里有个新手特别容易搞混的点——cwd 是进程级的不是终端级的也不是用户级的。你开两个终端窗口它们是两个独立的 shell 进程各有各的 cwd互不干扰你在一个窗口里cd到了别处另一个窗口纹丝不动。理解了这一层再看cd这个命令就好办了它干的事情本质上只有一件——把当前 shell 进程的 cwd 换掉。换掉之后后续所有相对路径的解析基准就全变了。这也是为什么cd的影响范围是从这一刻起这个 shell 里执行的所有命令而不是这一个命令。很多人写脚本时习惯在开头cd一下然后一路相对路径往下走就是吃了这个特性的红利反过来忘了cd回去或者cd到了错误的地方后面的操作就全歪了。1.2 点、双点、斜杠、波浪号四个符号四种出身这四个符号虽然经常一起出现但它们的出身完全不同搞清楚这一点区别自然就出来了。.和..是文件系统层面真实存在的目录项。每个目录在被创建的时候内核会自动往里塞两条硬链接一条叫.指向自己一条叫..指向父目录。所以你ls -a任何一个目录都能看到这俩货。它们是实实在在的目录条目由文件系统维护内核在做路径解析时会直接处理跟你用哪个 shell 没关系。根目录的..有点特殊它指向自己所以你在/下执行cd ..永远不会报错只会原地踏步。/单独出现时是根目录这个节点的名字它同时还是路径分隔符。这两个身份要分开看作为分隔符时它只是个符号比如/usr/bin里那两个斜杠作为独立路径时它是树的顶点。~的出身最不一样它是shell 层面的展开符号文件系统里根本不存在叫~的目录。你敲下cd ~回车之前shell 已经先把~替换成了$HOME的值然后才把替换后的结果交给cd。这个顺序很重要后面讲失效场景时会反复用到。顺带说一句~的展开规则属于 shell 的波浪号展开tilde expansion范畴和变量展开、通配符展开是并列关系规则细节各 shell 略有差异。1.3 为什么这三个写法特别容易糊在一起我观察下来混淆主要来自三个认知惯性。第一日常使用中三者经常看起来都回到了某个熟悉的地方比如你从/home/user/project/src出发cd ..到了projectcd ~到了/home/usercd /到了根三个操作都让你离开了当前目录体感相似于是大脑就懒得区分了。第二教程里往往只给一条命令加一句回到上级目录不解释边界条件等你真遇到符号链接、遇到 HOME 没设、遇到在根目录下操作才发现那句话说漏了一大半。第三也是最阴的一个这三个写法在正常情况下都能跑通只有在边界情况下才暴露差异。而脚本恰恰最容易撞上边界情况——定时任务里的环境变量是精简的容器里的 HOME 可能压根没设CI 里跑的位置和你想的不一样。所以我一直建议别等到出事再去查趁着现在没出事把这三个写法的行为边界一次性搞清楚成本极低收益是长期的。2. 三种写法在实际行为上的差异拆解2.1cd ..相对上级走到哪算哪cd ..的语义是进入当前工作目录的父目录。注意这里的当前工作目录是个变量所以这条命令的结果完全取决于你执行时站在哪儿。在/home/user/project/src下执行落到/home/user/project在/etc/nginx下执行落到/etc在/下执行还是/。它是一条跟着你走的命令没有任何固定目标。正因为结果不固定cd ..在脚本里是最容易出事的写法之一。你写脚本时脑子里想的是从脚本所在目录往上退一级找到项目根可脚本被别的东西调用时cwd 可能是任意位置cd ..退到的自然也是任意位置。这类 bug 有个特点本地测的时候一切正常上了定时任务或者被别的脚本 source 之后就疯了排查起来极其费劲因为代码本身一个字都没改。还有一个细节值得单独拎出来cd ..在符号链接场景下的行为取决于 shell 用的是逻辑路径还是物理路径。bash 默认走逻辑模式相当于cd -L它维护的PWD是你走过来的那条路所以cd ..退的是逻辑上的上一级而cd -P ..会先按物理路径解析退的是真实文件系统结构上的父目录。这两者在有软链的目录树里结果可能完全不一样后面第 3 章会拿具体例子跑一遍。2.2cd /绝对定位最没有歧义的一条cd /是三兄弟里最死的一条不管你在哪儿、HOME有没有设、CDPATH配成什么样它的目标永远是根目录。执行完之后pwd一定是/没有例外没有条件分支。这种确定性在脚本里特别值钱——当你需要一个绝对干净的起点时cd /是唯一能保证结果的选择。但它的死也意味着风险根目录是整个文件系统的顶点从这儿往下走的路都是绝对路径你一旦在根下做了什么事影响面就是全系统。我见过有人在部署脚本开头写cd /想回到干净状态结果后面的相对路径rm -rf tmp/*直接作用到了系统根下的/tmp而不是项目里的tmp目录。所以用cd /的时候必须保证后面的所有操作都用绝对路径或者立刻cd到明确的目标目录别在根目录下停留太久。另外提一句cd /在权限上没门槛根目录对所有用户都有执行权限但在容量上有讲究——很多系统把根分区做得很小你在根下随手建目录写文件容易把分区撑满进而影响日志、临时文件、甚至系统启动。这是我带人时反复强调的一条别把根目录当工作区。2.3cd ~看起来是回家其实是变量展开cd ~的直觉含义是回到自己的家目录这句话在绝大多数情况下成立但它成立的原因不是cd有什么特殊逻辑而是 shell 在调用cd之前把~换成了$HOME的值。所以准确的说法是cd ~等价于cd $HOME~只是个人类友好的简写。这个区别在什么时候会咬人第一HOME没设或者为空的时候。某些精简环境、某些以特定方式启动的进程、某些容器镜像里HOME可能压根不存在。这时cd ~在 bash 里会直接报错提示类似HOME not set而cd不带任何参数的行为也依赖HOME同样会失败。第二~被引号包住的时候。cd ~不会展开成家目录因为引号里的内容不参与波浪号展开shell 会老老实实找一个名字就叫~的目录找不到就报错。第三~后面跟用户名时比如~someuser展开目标是那个用户的家目录但你能不能进去还得看权限这是另一回事。还有一个隐藏的坑cd ~的目标由HOME决定而HOME是可以被覆盖的。你在脚本里改了HOME去做测试后面的cd ~就跟着跑偏有些工具为了让配置隔离也会临时改HOME这时候回家回的就是那个临时的家。这个行为本身是合理的设计但如果你不知道就容易怀疑人生。2.4 一张表把差异摆平写法目标由什么决定结果是否固定依赖环境变量典型失效场景cd ..当前工作目录的父目录否随 cwd 变化否脚本 cwd 不可控符号链接下逻辑/物理路径不一致cd /文件系统根目录是永远是/否后续相对路径误伤系统目录根分区空间被占cd ~$HOME的值否随 HOME 变化是HOMEHOME 未设/为空/被改写被引号包裹导致不展开这张表建议直接抄进你的备忘里。判断该用哪个的标准其实很简单你要的是确定的位置还是相对于现在的位置。要确定的位置用绝对路径或者cd /要相对位置才用cd ..。而cd ~只在我确实要回家且我确认 HOME 可信的时候用脚本里更稳妥的做法是直接写cd $HOME至少你一眼能看出它依赖什么。3. 底层原理cd为什么必须是内建命令3.1 从chdir系统调用说起想知道cd为什么跟ls、grep这些命令不是一类东西得先明白进程模型。每个进程有自己的地址空间、自己的文件描述符表、自己的 cwd。cwd 是进程的私有属性存在内核里用户态程序想改它只能通过系统调用chdir()或者fchdir()用文件描述符来切。这个调用的效果是把调用者自己这个进程的 cwd 换掉仅此而已。问题就来了。你在 shell 里敲lsshell 会 fork 出一个子进程去执行ls执行完子进程退出父进程shell继续等你的下一条命令。如果cd也是一个外部程序那么它被 fork 出来、调用chdir()改了 cwd、然后退出改的是它自己那个短命进程的 cwd父进程 shell 的 cwd 一点没变。你敲完cd /tmp再看pwd还在原地命令等于白敲。所以cd必须是 shell 自己实现的内建命令builtinshell 在自己的进程里直接调chdir()改的才是那个真正影响后续所有命令的 cwd。POSIX 里甚至把cd归为特殊内建命令special built-in在查找顺序、错误处理上都有额外的规定。这也解释了一个常见困惑为什么which cd在有些系统上给不出可执行文件路径因为压根就没有对应的二进制文件。顺带说一个推论任何想改变父 shell 环境的操作都必须是内建命令或者被source执行比如cd、export、umask。你用bash -c cd /tmp是没用的那只改了子 shell 的目录同理脚本里cd了没用因为脚本本身跑在子 shell 里——除非你source它。这个点很多人在写切换目录的脚本时栽过跟头。3.2PWD与OLDPWDshell 帮你记的账bash 在你每次成功cd之后会同步维护两个环境变量PWD存当前目录OLDPWD存上一次的目录。cd -就是靠OLDPWD实现的它会切回去并且把目标路径打印出来方便你确认。这也是为什么cd -在线上一层层退的时候特别好用比手敲一长串路径靠谱得多。这里有个容易忽略的事实PWD是 shell 维护的逻辑路径不一定等于内核里那个物理 cwd。在 bash 默认的-L模式下你从软链进去、再往上退PWD记录的是你走过的那条路看起来更符合人的直觉但和文件系统真实结构可能有出入。想要看物理路径用pwd -P或者干脆cd -P切到物理模式。我个人的习惯是在脚本里不信任PWD的直白含义需要确定位置时用pwd -P拿到物理路径再操作。特别是在有软链的部署目录里逻辑路径和物理路径分叉是很常见的你不搞清楚自己在哪一层写出来的相对路径就是薛定谔的。3.3 符号链接下的逻辑与物理之争拿个虚构场景跑一遍就明白了。假设有这么一个结构/data/app是真实目录/data/current是一个指向/data/app的符号链接。你先cd /data/current然后pwdbash 默认会告诉你/data/current——这是逻辑路径。此时你执行cd ..落在哪儿在默认的逻辑模式下bash 认为你的上一级是/data所以cd ..之后你在/data。但如果你用cd -P ..bash 先把/data/current解析成物理路径/data/app再取父目录结果还是/data这里恰好一样。真正分叉的情形是软链跨了层级比如/data/current指向/opt/releases/v3/app这时候逻辑上退一级是/data物理上退一级是/opt/releases/v3差别就出来了。这个差异不是学术问题。部署脚本里用软链做版本切换current指向某个版本目录是极常见的做法脚本里如果用cd ..去定位项目根在逻辑模式下和在物理模式下拿到的目录可能压根不是同一个后面的相对路径自然全错。稳妥的做法是要么全程用绝对路径要么用cd -P明确按物理结构走别让默认行为替你做决定。3.4HOME为空时到底会发生什么HOME未设置的情况下不同 shell 的表现略有差异但共同点是cd ~和裸cd都会失败而不是猜一个默认目录。bash 的报错大意是提示HOME没有设置某些 shell 可能退回到密码库里记录的家目录但这属于实现细节不能当成可依赖的行为。在容器化环境里这个坑出现的频率不低。有些精简镜像为了减小体积创建用户时不写完整的家目录信息或者启动进程时环境被清理得很干净HOME就空了。这时候脚本里一句cd ~直接让整个流程挂掉。解决办法不复杂要么在脚本开头显式export HOME/some/path前提是你知道该指哪要么干脆别用~直接写死绝对路径。我倾向于后者脚本里出现~的地方越少越好因为它把脚本的正确性绑定在了一个外部变量上。还有个小细节cd ~在HOME指向一个不存在或者没权限的目录时报错信息是没有那个目录或权限不够跟HOME没设的报错不一样。排查的时候先看报错内容能省不少时间。4. 完整实操把每种行为亲手验一遍4.1 先搭一个安全的实验沙箱理论讲完得动手。我建议所有验证都在一个临时沙箱里做别拿真实项目目录练手免得一个手滑把不该动的东西动了。下面这套步骤在任何常规系统上都能跑全程只在自己建的临时目录里折腾。# 建一个实验场位置放在用户临时目录下 mkdir -p /tmp/cd-lab/data/app/v3/bin mkdir -p /tmp/cd-lab/data/releases/v3 cd /tmp/cd-lab ln -s /tmp/cd-lab/data/releases/v3 /tmp/cd-lab/data/current ls -la /tmp/cd-lab/data跑完你会看到current是个指向releases/v3的软链app是另一个独立的真实目录。这套结构故意做成软链和真实目录混在一起就是为了把逻辑路径和物理路径的差异逼出来。先别急着往下走确认一下ls -la的输出里箭头方向对得上软链建错了后面全白搭。沙箱建好后我习惯先在纸上或者注释里写清楚我预期会看到什么再跑命令。这个习惯看着多余实际上是排查能力的基本功预期和实际的差异才是信息的来源。如果你跑完只是看一眼觉得哦好像对那这一遍基本白跑。4.2 逐条验证三种写法先验cd ..的相对性。从深目录出发往上退观察每一级的pwdcd /tmp/cd-lab/data/app/v3/bin pwd # /tmp/cd-lab/data/app/v3/bin cd .. pwd # /tmp/cd-lab/data/app/v3 cd .. pwd # /tmp/cd-lab/data/app cd ../.. pwd # /tmp/cd-lab/data注意最后那条cd ../..它是连续退两级等价于连敲两次cd ..。这种写法在脚本里能省行数但可读性会下降我一般只在很明确的两级场景用。再验一下根目录的边界cd / pwd # / cd .. pwd # 仍然是 /这一条说明cd ..不会退出去根目录的父目录就是它自己。很多新手担心在根下cd ..会出错其实不会但也别指望它带你去别的地方。再验cd /的绝对性。这个最简单随便站在哪儿执行都一样cd /tmp/cd-lab/data/app cd / pwd # /最后验cd ~的展开本质。关键是看它到底依赖什么echo $HOME # 比如 /home/someuser cd ~ pwd # /home/someuser cd ~ # 报错没有那个文件或目录第三条命令就是那个经典陷阱加了引号~不展开shell 去找一个名字字面叫~的目录当然找不到。这一条我建议每个人都亲手跑一次报错长什么样记住了以后遇到能秒认。4.3 把软链下的一级一级退出来看清楚这一步是整个实操里最有价值的部分。进软链然后用两种模式分别退一级cd /tmp/cd-lab/data/current pwd # /tmp/cd-lab/data/current 逻辑路径 cd .. pwd # /tmp/cd-lab/data 逻辑上的上一级 cd /tmp/cd-lab/data/current pwd -P # /tmp/cd-lab/data/releases/v3 物理路径 cd -P .. pwd -P # /tmp/cd-lab/data/releases对比一下两次pwd的结果同一个起点cd ..到了/tmp/cd-lab/datacd -P ..到了/tmp/cd-lab/data/releases。差了整整一层。这不是 bug是两种路径视角的必然结果。你在写部署脚本时如果用了软链做当前版本的指针就务必要想清楚我要的是软链所在目录的上一级还是真实版本目录的上一级。这两个答案经常不一样而且错的那个通常不会立刻报错只会在后续操作里悄悄写错地方。再补充一个验证OLDPWD和cd -的小实验cd /tmp/cd-lab/data/app cd /tmp/cd-lab/data/releases cd - # 输出 /tmp/cd-lab/data/app 并切过去 cd - # 又切回 /tmp/cd-lab/data/releasescd -会打印目标路径这个打印行为在交互式使用时很贴心但在脚本里会污染标准输出。所以脚本里要用cd -的话记得把输出重定向掉比如cd - /dev/null。4.4 脚本里到底该怎么选把上面的验证结论落到工程实践我的建议可以归纳成几条硬规则。第一脚本开头先定位自己再谈其他。不要假设调用者的 cwd用脚本自身路径反推目录SCRIPT_DIR$(CDPATH cd -- $(dirname -- $0) pwd -P) cd $SCRIPT_DIR || exit 1这段看起来有点绕但每一段都有理由。CDPATH是为了屏蔽用户环境里配置的搜索路径那玩意儿会让cd跑到意料之外的地方--是为了防目录名以短横线开头被当成选项$(dirname -- $0)拿到脚本所在目录pwd -P拿物理路径绕开软链歧义保证目录切换成功才取路径|| exit 1是防止切换失败后继续往下跑在错误的位置干错误的事。第二需要确定位置就写绝对路径别用cd ..去猜。cd ..在交互式终端里很舒服在脚本里就是不确定性的一大来源。真要退一级用cd $(dirname $PWD)之类显式表达意图的写法让读代码的人一眼看出你在干什么。第三别在根目录下停留。cd /之后立刻切到目标目录中间不要插入任何相对路径的操作。这条是纯粹的经验之谈出过事的人自然懂。第四环境变量该兜底就兜底。脚本里如果需要家目录先判断HOME是否存在if [ -z ${HOME:-} ]; then echo HOME 未设置无法确定目标目录 2 exit 1 fi这种防御性代码看着啰嗦但在容器、定时任务、CI 这些环境里能救你很多次。我现在的习惯是所有依赖环境变量的脚本入口处统一做一遍校验缺什么报什么别等到跑到一半才炸。5. 常见问题与排查实录5.1 高频问题速查表下面这张表是我这些年被问得最多、自己也踩得最多的问题合集遇到现象直接对号入座。现象最可能的原因排查动作处理办法cd ~报 HOME 未设置运行环境里HOME为空echo [$HOME]看是否为空显式指定绝对路径或补设HOMEcd ~报目录不存在引号阻止了波浪号展开看命令里~是否被引号包住去掉引号或改用$HOME脚本里cd后路径仍不对脚本跑在子 shell 里或 cwd 非预期在脚本开头打pwd确认起点用脚本自身路径定位别依赖调用者 cwd软链目录下cd ..位置不符预期逻辑路径与物理路径不一致对比pwd与pwd -P明确用cd -L或cd -P别靠默认cd /后相对路径操作误伤系统目录在根下使用了相对路径检查后续命令里是否有相对路径全部改绝对路径或立刻切到目标目录cd -输出干扰脚本cd -会打印目标路径看脚本标准输出里是否混入路径重定向到/dev/nullcd到某目录提示权限不够目标目录缺少执行搜索权限ls -ld看权限位补x权限或换有权限的路径补充一点权限的细节进入一个目录需要的是执行权限对目录来说叫搜索权限只有读权限是进不去的只能列目录名。这个点在排查为什么我能ls但不能cd时特别有用很多人第一反应是去查所有者其实问题就在权限位上。5.2 脚本里的三个隐蔽坑第一个坑是CDPATH。这个变量平时几乎没人用但一旦有人在你环境里设了它cd的查找顺序就变了它会在当前目录找不到时去CDPATH列出的目录里找同名的子目录。在交互式场景这可能是个便利功能在脚本里就是灾难因为cd logs可能切到一个完全无关的地方而且不报错。所以脚本里凡是cd前面都带上CDPATH清零成本很低。第二个坑是cd失败但脚本继续跑。cd失败时返回非零退出码但如果你用的是;连接或者没检查返回值后面的命令照样在原来的目录里执行。这时候破坏力反而更大——你以为在项目目录里删临时文件实际在别的地方删。所以关键位置的cd一定要跟或者|| exit 1别让失败被吞掉。第三个坑是把cd写进管道或者子 shell 里。比如(cd /tmp do_something)这个写法本身没问题但要清楚它只影响括号里的子 shell外面的 cwd 不变。有些人指望用这种写法临时切目录然后自动回来思路是对的但得接受一个事实里面的所有操作都发生在子 shell 里外面拿不到里面设置的任何变量。想保留效果就得把结果通过标准输出传出来。5.3 几条不怎么写在文档里的实操心得第一条在交互式终端里cd -比cd ..好用得多。你从 A 目录跳到 B 目录干活干完想回去cd -一步到位而cd ..得数清楚退几级目录深一点就数错了。我现在的习惯是重要目录之间来回切全用cd -只有明确的层级关系才用..。第二条给常用目录设书签式的变量但别用~去凑。比如export PROJ/data/work/project-x然后cd $PROJ。这么写的好处是位置集中管理改一处全生效而且不依赖HOME这种容易被改的外部变量。比起在每个脚本里cd ~/work/project-x可维护性高一个量级。第三条排查目录问题时先打pwd -P再动手。我养成了一个近乎条件反射的动作只要进入一个不熟悉的目录、或者目录路径里带软链第一件事就是pwd加pwd -P各打一次两边一对比心里立刻有数。这一个动作帮我省掉的排查时间比我学过的任何调试技巧都多。第四条别在脚本里用cd ~用cd $HOME。理由前面说过写出来依赖关系一目了然读代码的人不用在脑子里做一次展开运算。而且如果哪天HOME被改了$HOME的写法在代码审查时更容易被注意到~则容易被眼睛自动忽略过去。说到底这三个写法没有哪个更好只有哪个更匹配你当下的意图。cd /是绝对定位cd ..是相对上级cd ~是变量展开。把这个判断标准记住比背一堆用法例句管用得多。我现在写脚本凡是涉及目录切换的地方都会先问自己一句这里我要的是确定的位置还是相对的位置答案清楚了代码自然就写对了。