刚接触Linux那会，我特别不理解为啥敲个pwd还有那么多讲究，不就是打印当前目录嘛。直到有一次在脚本里拼路径，因为没搞清楚pwd -P和pwd -L的区别，把日志输出位置搞错了，排查了半天才回过神。从那以后我就明白，越是基础的Linux命令，越值得把它背后的逻辑彻底弄透。这篇内容围绕Linux里出现频率最高的pwd命令展开，把它的用法、参数、原理、脚本技巧和运维实战场景一次讲清楚，适合刚入门的新手，也适合想补基础短板的运维、开发和面试党。
pwd全称是print working directory，作用就一个：把当前所在的目录路径打印出来。看起来简单，但它在shell交互、脚本编写、路径拼接、日志定位这些场景里属于不可或缺的底层命令。很多人用了好几年Linux，可能只在迷路的时候才想起敲一下pwd，实际上它有几个参数和行为细节，一旦没弄明白，真到了线上环境就会踩坑。
1. 认识pwd命令：基本用法与Shell工作机制
1.1 pwd的基本命令格式与参数
先看最基础的东西。pwd的语法格式非常简单，通常不需要任何参数，直接执行就能输出当前目录的绝对路径：
$ pwd /home/ubuntu/project它支持的参数主要有两个：
pwd -L # 逻辑路径，跟随环境变量PWD，默认行为 pwd -P # 物理路径，绕过符号链接，显示真实目录-L是logical的缩写，-P是physical的缩写。不同发行版、不同shell里默认行为略有差异，Bash里默认等效于-L，而/bin/pwd这个独立程序在不加参数时默认是-P。这个差异非常关键，后面我会用实际案例演示它到底怎么坑人。
提示：在绝大多数Linux发行版里，shell内置的
pwd是默认优先的。你可以用type -a pwd查看它的完整来源路径，通常能看到pwd is a shell builtin和/usr/bin/pwd两个结果。
1.2 为什么需要pwd：Shell工作目录机制
理解pwd之前，得先理解Shell的"当前工作目录"（Current Working Directory，简称CWD）到底是什么。每个Shell进程，甚至每个子进程，都维护着一个属于自己的目录状态。当你执行ls、touch、cat这些命令时，如果没有指定绝对路径，操作系统就会默认在这个状态对应的目录里寻找文件。
这个状态本质上是由内核维护的进程属性，Shell只是负责展示和修改它。cd命令修改的是当前Shell进程的目录属性，pwd则是向内核查询当前目录并打印出来。用一句生活化的话说：Shell进程就像你在办公楼里的工位，cd是换工位，pwd是告诉别人你现在坐在哪一层哪一排。
由于每个子Shell都有自己独立的目录状态，所以在脚本里用cd切换目录后不会影响父Shell的所在位置。这就是为什么很多部署脚本里常用(cd /path && command)这种子Shell写法，也是理解后面脚本技巧的基础。
2. pwd两个核心参数：-L与-P符号链接的逻辑差异
2.1 符号链接场景下的pwd -P真实路径获取
这个案例是我当年踩坑的起点。假如你有一个目录/data/web，它其实是指向/home/www/htdocs的符号链接：
$ ls -ld /data/web lrwxrwxrwx 1 root root 14 Jan 1 10:00 /data/web -> /home/www/htdocs当你cd /data/web之后再执行pwd，很多时候会看到路径仍然是/data/web，而不是解析后的真实路径/home/www/htdocs。这就是pwd -L的逻辑路径行为：它信任PWD环境变量记录的内容，而PWD这个变量在cd的时候就被Shell更新成了你输入的路径。
如果你使用pwd -P，Shell会调用系统调用getcwd()向内核重新查询真实路径，输出/home/www/htdocs。那到底什么时候必须用-P？最常见的场景是配置文件和启动脚本。有些程序会把当前路径写入配置，如果当前路径包含符号链接，后续进程从不同入口访问目录时，可能出现路径不一致的问题。例如Nginx的nginx.pid路径、日志切割脚本里的BASE_DIR，如果路径解析不彻底，用符号链接进入和用真实路径进入会看到两个不一样的结果，排查起来非常痛苦。
2.2 默认-L行为与PWD环境变量的关系
-L逻辑路径的逻辑基础，是Shell内部维护的PWD环境变量。这个变量在每次cd时都会被更新，你可以手动验证一下：
$ export PWD=/tmp $ pwd /tmp $ pwd -P /home/ubuntu看到没有？在不改变当前实际目录的情况下，我把PWD变量手动改成/tmp，pwd -L输出就变成了/tmp，而pwd -P输出的仍然是真实路径。这说明-L本质上就是"打印PWD变量"，是个纯逻辑行为。
这个特性在某些特殊场景下会被刻意利用。有的脚本不想暴露服务器的真实目录结构，会在子进程启动前重设PWD变量，让程序以为自己工作在另一个目录。但绝大多数情况下，这种花活不建议用，因为它容易让日志路径错乱，出了问题非常难定位。我见过有同事在CI流水线里为了图省事直接导出PWD，结果后面所有相对路径解析全乱了。
2.3 Shell内置版与/bin/pwd外部命令的区别
pwd在Linux里有两套实现：一套是Bash等Shell自带的builtin命令，另一套是GNU coreutils提供的/bin/pwd独立程序。日常使用中你敲的pwd大概率命中内置版本，需要留意的是它们默认参数不一样：
| 实现方式 | 默认行为 | 查看方法 |
|---|---|---|
| Shell内置pwd | 默认-L | type -a pwd |
| /bin/pwd程序 | 默认-P | /bin/pwd |
这么设计有历史原因。Bash作为交互Shell，希望尽量保持用户看到的路径与输入一致，所以跟随PWD变量；而GNU工具集作为系统命令，更强调返回真实可靠的内核路径。如果你在脚本里为了追求确定性，建议不要只写pwd，而是显式写pwd -P或/bin/pwd，避免不同系统、不同shell带来的行为漂移。这个细节在面试里也经常被拿来考察候选人是否真的理解命令底层差异。
3. pwd在Shell脚本与自动化运维中的实战技巧
3.1 脚本中获取当前目录的经典写法
写Shell脚本时，经常需要知道脚本自身所在目录，然后基于这个目录去加载配置、引用依赖或者拼接日志路径。很多新手直接写：
cd $(dirname "$0")这行代码在大多数情况下没问题，但一旦脚本被符号链接调用，或者从别的目录执行，$0的值未必是你以为的那个路径。更稳妥的写法是结合pwd -P做一次路径解析：
#!/bin/bash # 获取脚本真实路径的经典写法 SOURCE="${BASH_SOURCE[0]}" while [ -h "$SOURCE" ]; do DIR="$(cd -P "$(dirname "$SOURCE")" >/dev/null 2>&1 && pwd -P)" SOURCE="$(readlink "$SOURCE")" [[ $SOURCE != /* ]] && SOURCE="$DIR/$SOURCE" done SCRIPT_DIR="$(cd -P "$(dirname "$SOURCE")" >/dev/null 2>&1 && pwd -P)"这段代码虽然看起来啰嗦，但其中每一步都有明确目的：循环处理符号链接，直到拿到真实路径；使用pwd -P确保返回的目录不包含任何软链成分。对于分发到多台服务器并且经常被软链到/usr/local/bin的运维脚本来说，这套写法能直接避免路径错乱问题。
注意：脚本里
cd到某个目录后，后续如果要回到原始目录，不要想当然以为pwd输出不会变。建议在脚本开头先用ORIG_DIR=$(pwd -P)保存现场，所有操作结束后再cd "$ORIG_DIR"回来。
3.2 目录被删除后pwd抛出的异常行为
还有一个容易被忽略的细节是：当Shell当前所在目录被其他进程删除后，执行pwd会看到什么？实测结果很有意思。
$ mkdir /tmp/testdir $ cd /tmp/testdir $ rmdir /tmp/testdir $ pwd -bash: pwd: (2, No such file or directory) /tmp/testdir这里的输出其实是Bash内置pwd的一种特殊表现：它先尝试查询真实物理路径，发现目录已经不存在，于是打印一条错误信息到标准错误，然后仍把PWD变量中的逻辑路径打印出来。而/bin/pwd行为不太一样，它直接返回非零退出码，并且不输出路径。
这个现象在日常操作中一旦遇到，说明你所在目录已经被外部清理掉了。在很多日志清理脚本、临时目录自动删除服务存在的情况下，进程长时间运行后目录被删是常态。这时候如果脚本里还在用相对路径读写文件，就会意外地写到别的地方去，因为当前目录其实已经变成了文件系统根目录或其他无法确定的位置。所以监控脚本里检测工作目录有效性时，不能只看命令输出有没有内容，还要检查退出码：
if ! pwd -P >/dev/null 2>&1; then echo "当前目录已失效，尝试切换到安全目录" >&2 cd /tmp || exit 1 fi3.3 pwd与cd、dirname、OLDPWD的组合用法
pwd单独用价值有限，真正有威力的是和cd、dirname、basename、OLDPWD等合起来用。OLDPWD是Shell自动维护的上一次目录变量，配合cd -可以快速在最近两个目录间切换。很多时候我排查问题时先记下当前目录，再跳去配置文件目录，改完直接cd -回来，靠的就是$OLDPWD。
另一个高频组合是取上级目录。比如当前在/home/ubuntu/app/bin，想回到/home/ubuntu/app：
$ cd "$(dirname "$(pwd)")"这个写法比cd ..更稳健，尤其当路径是以变量形式从配置中心读进来时，你根本不知道它末尾带不带斜杠、到底有几层目录。还有更简洁的：
$ cd ..这里两种方式有本质区别：cd ..依赖Shell对路径字符串的解析，如果当前目录被删除，cd ..可能失败；而通过dirname "$(pwd -P)"先生成目标路径再cd，能多一层保障。我在清理临时目录时习惯用后者，比如删除某个目录后需要自动化切换到它的上一级，这样即使目标已被删，路径仍然可计算。
pwd还可以用来校验脚本的执行上下文。比如你有一个只允许在项目根目录运行的部署脚本，可以直接写：
if [ "$(basename "$(pwd -P)")" != "myproject" ]; then echo "请在项目根目录执行本脚本" >&2 exit 1 fi这种方式比单纯检查某个文件是否存在更能表达意图，也方便别人维护时理解脚本的运行前提。
4. pwd相关面试考点与常见问题排查
4.1 面试和考证中关于pwd的高频问题
pwd在Linux面试题里出现频率不低，原因在于它能够连带考察环境变量、符号链接、Shell内置命令优先级等多个知识点。常见的问题包括：
问题1：pwd和/bin/pwd有什么区别？
核心考点是Shell builtin与外部命令的关系，以及两者默认参数不同。回答时如果能提到type -a pwd查看完整路径、-L与-P的差异，基本就能拿分。
问题2：在符号链接目录里执行pwd，为什么显示的是链接路径而不是真实路径？
核心考点是PWD环境变量的作用机制。如果候选人不清楚Bash默认-L行为，很容易在这个问题上卡住。
问题3：Shell脚本如何可靠获取自身所在目录？
这个属于实操考察。答案里如果没有pwd -P和readlink对符号链接的处理，通常是经验不足的表现。
问题4：为什么有时候执行pwd会打印"No such file or directory"？
核心是当前目录已被删除，内置pwd与外部pwd对错误处理不同。这属于比较深入的问题，能答上来的人很少是背题背出来的。
遇到这类题目，我的建议是别只背结论，自己搭几个目录结构实验一遍，印象会深得多。
4.2 pwd使用中的常见问题速查表
| 现象 | 原因 | 解决办法 |
|---|---|---|
pwd和pwd -P输出不一致 | 当前目录包含符号链接，默认逻辑路径与物理路径不同 | 需要真实路径时显式加-P |
脚本里用pwd拿到和预期不一样的路径 | PWD环境变量被修改，或脚本被符号链接执行 | 统一改用pwd -P |
执行pwd返回No such file or directory | 当前目录已被外部删除 | 检查业务进程是否清理了工作目录；cd /tmp后重新操作 |
type -a pwd显示两个结果 | 一个是Shell内置，一个是外部程序 | 正常现象，不必处理；想用外部版可写/bin/pwd |
cd进目录后pwd没变化 | 可能是调用了别名或函数，并没真正切换 | 使用type cd查看是不是被别名劫持 |
排查问题时pwd输出正确但程序仍找不到文件 | 程序的工作目录可能是它自己启动时设定的，不是当前Shell目录 | 检查进程的/proc/<PID>/cwd符号链接 |
这里特别提一下/proc/<PID>/cwd，它是一个指向进程当前工作目录的符号链接。实际排查问题时，如果一个后台进程行为异常，可以用：
$ ls -l /proc/12345/cwd来查看这个进程真正的工作目录。这条命令是pwd思路的延伸——它是从内核视角看问题，而不是依赖Shell环境变量。我在定位定时任务脚本路径问题时，这招救过好几次场。
4.3 让pwd输出更易读的现场小技巧
纯pwd输出的是绝对路径，但有时候路径太长，看起来不方便。有几个思路可以优化，比如在交互Shell里的提示符中加入当前目录。大部分人会用\w（完整路径）或\W（仅当前目录名）来定制PS1。我个人喜欢把PS1里的路径部分设置成：
export PS1='[\u@\h \W]\$ '\W只显示最后一级目录名，这样即使深陷/home/ubuntu/app/config/nginx/conf.d这种层层嵌套的目录，提示符也不会被撑爆。需要完整路径时再敲pwd或者用\w，这个平衡在长时间运维操作中很实用。
再分享一个给pwd输出加颜色的方式。如果你在终端里希望当前路径高亮，可以在~/.bashrc里定义个函数：
function pwd_color() { pwd -P | sed "s|^$HOME|~|" }这只是个简单示例，实际生产环境里我很少给命令输出做过多美化，因为脚本解析时颜色转义码会干扰输出。如果只是给人看，怎么舒服怎么来；如果要供程序读取，请保持pwd输出纯净，绝对不要包颜色码。
5. 我对pwd的最佳实践总结与一条额外提醒
从入门到现在，我对pwd的认知经历了一个从"太简单不用学"到"细节里藏坑"的过程。如果你只想记一条最重要的经验，那就是：在脚本里获取当前目录，一律显式使用pwd -P，不要依赖Shell默认行为。默认行为在不同环境里可能不同，而显式参数能保证你的脚本在任何发行版、任何shell下行为一致。这也是很多开源项目里的安装脚本为什么总是写$(cd "$(dirname "$0")" && pwd -P)的原因——它不是炫技，而是为了让脚本在符号链接、跨目录执行等情况下依然拿到准确位置。
最后再提醒一个容易被忽略的点：pwd是查询当前Shell进程工作目录，如果你在管道、子Shell或者$(...)中执行命令，它拿到的是子进程的目录状态，不是父Shell的。比如你写cat file | while read line; do pwd; done，当循环里执行了cd，它只影响子Shell内部，退出循环后并不会改变你的当前位置。想要在循环里累积目录切换，该用变量传递就用变量传递，不要指望cd能透过子Shell生效。理解了这个层次，你对pwd的掌握就算真正通透，以后再遇到路径相关的诡异问题，至少知道从哪里开始排查。
