这个命令是干啥的
pwd，Print Working Directory。太基础了，基础到很多人从来不把它当成一个"命令"来看。
我刚学 Linux 那会儿觉得 pwd 就是敲一下看看自己在哪儿，没啥好学的。直到有一天我被软链接坑了，才意识到 pwd 还有两副面孔。
事情是这样的。有一次我为了图方便，在 /home/ubuntu/project 下建了个软链接指向 /data/nginx/html，叫 www。我 cd www 进去之后执行 pwd，显示的是 /home/ubuntu/project/www。然后我在一个部署脚本里用 pwd 拼路径，结果文件全都写到了软链接路径里，压根没写进真实目录。排查了半小时，才发现是 pwd 的 -P 和 -L 的区别。
从那以后我再也不敢小看 pwd 了。
基本用法（3分钟上手）
pwd 的用法极其简单：
# 直接打印当前目录
pwd
多数情况下输出就是你看到的路径，没啥猫腻。但遇到软链接的时候就有区别了。
# 软链接路径指向的真实物理路径
pwd -P
# 保持软链接的逻辑路径
pwd -L
-P 是 Physical，显示真实的物理路径，遇到软链接会解析出它指向的真实地址。
-L 是 Logical，显示逻辑路径，保持你 cd 进去的软链接路径，不解析。
默认情况下大多数 shell 的 pwd 是 -L 模式。但不同发行版可能有差异，最好别靠猜。
# 查看当前shell的pwd行为
type pwd
# 大多数bash里pwd是shell内置命令
# /bin/pwd 是外部命令，行为可能不同
bash 内建的 pwd 默认 -L，而 /bin/pwd 默认 -P。这个差异踩过的人才知道。
进阶骚操作
$PWD 环境变量：
# $PWD 里存着当前路径
echo $PWD
# 更精确，跟pwd -L一样
echo "$PWD"
$PWD 和 $OLDPWD 是 shell 自动维护的两个变量。$PWD 存当前目录，$OLDPWD 存上一个目录。
# 用$PWD拼路径
ls -la "$PWD/config/nginx.conf"
# 相当于
ls -la /current/path/config/nginx.conf
脚本里验证路径：
# 判断当前是不是在指定目录
if [ "$PWD" = "/var/log" ]; then
echo "在日志目录"
fi
# 更灵活的方式，用通配符
if [[ "$PWD" == "/data/project/"* ]]; then
echo "在项目目录下"
fi
用 pwd 同步路径：
# 在两个终端窗口里，想知道当前在哪个目录
# 一个终端里执行
pwd > /tmp/current_path
# 另一个终端里读
cd $(cat /tmp/current_path)
这个在排查问题的时候配合 tmux 特别好用。两边目录一致了，看同一个配置文件，不会搞混。
获取脚本自身的目录：
写脚本时经常需要知道自己在哪里：
#!/bin/bash
# 获取脚本所在的真实目录（不管从哪执行）
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd -P)"
echo "脚本在: $SCRIPT_DIR"
这里的 pwd -P 确保拿到的是物理路径。dirname 拿到脚本所在的目录名，cd 进去再 pwd，就拿到了绝对路径。
这条我几乎是每个脚本都会写一句，省了无数麻烦。
配合 readlink 看软链接指向：
# 查看当前目录是不是软链接
readlink -f .
# 查看软链接指向
readlink "$PWD"
readlink -f 比 pwd -P 更强，它会解析所有层的软链接，直到拿到真实路径。
避坑指南
坑1：cd 进入软链接目录后 pwd 不一致
这个就是我前面说的亲身经历。
# /home/ubuntu/www -> /data/nginx/html
cd /home/ubuntu/www
pwd
# 输出: /home/ubuntu/www （逻辑路径）
pwd -P
# 输出: /data/nginx/html （物理路径）
如果脚本里用了 pwd 后面再 mkdir logs，在逻辑路径下会在 /home/ubuntu/www/logs 里建目录。但如果你以为自己在 /data/nginx/html/ 下，那就在错误的地方写了文件。
坑2：cd /tmp; rm -rf * 这种操作
# 有人会在脚本里写
cd /tmp && rm -rf *
# 但如果你cd失败了（权限不足），rm会删当前目录
# 正确做法
cd /tmp && pwd -P | grep -q '^/tmp$' && rm -rf *
先验证 cd 成功了，再执行删除。我一般还会加个 pwd 确认。
坑3：$PWD 和 pwd 输出不一致
理论上它们应该一样，但有些情况不一样：
# 如果你手动改了$PWD
PWD=/fake/path
# 此时
echo $PWD # /fake/path
pwd # 还是真实的当前目录
$PWD 变量可以被覆盖，但 pwd 命令是 shell 内部维护的，不会骗人。所以脚本里判断路径用 pwd -P 比较靠谱。
坑4：在软链接层层嵌套时容易迷路
# a -> b -> c -> /data/real
# 你 cd 进了 a
pwd # /some/path/a
pwd -P # /data/real
# 中间跳过了b和c
软链接链太长的时候，pwd -L 和 pwd -P 差距很大。用哪个取决于你要干什么。写文件到磁盘的话，建议用 -P。
实战场景（重点！结合真实运维场景）
场景一：部署脚本里确保目录正确
部署脚本最怕的就是跑错目录。我的部署脚本开头一定会校验：
#!/bin/bash
DEPLOY_DIR="/data/app/myapp/releases/$(date +%Y%m%d%H%M%S)"
mkdir -p "$DEPLOY_DIR"
# 一定要cd进去再操作
cd "$DEPLOY_DIR" || { echo "cd失败"; exit 1; }
# 确认在正确位置
echo "当前部署目录: $(pwd -P)"
# 开始拉取代码
git clone git@github.com:myapp/repo.git .
# 后续操作...
多加一行确认目录的 pwd -P，能省掉你半夜被叫醒排查部署失败的时间。
场景二：日志采集脚本防止路径错乱
公司有一次日志采集脚本把日志写到了错误的位置，导致磁盘空间报警。查下来就是 pwd 的锅。
#!/bin/bash
# 日志采集脚本
LOG_BASE="/data/logs/app"
cd "$LOG_BASE"
# 这里用pwd -P确保路径解析正确
CURRENT_LOG_DIR="$(pwd -P)/$(date +%Y%m)"
mkdir -p "$CURRENT_LOG_DIR"
用 pwd -P 拿到解析后的绝对路径，再拼子目录，怎么都不会错。
场景三：脚本相互调用时的路径传递
多个脚本配合工作时，路径传递是常见问题：
# main.sh
PROJECT_ROOT="$(cd "$(dirname "$0")" && pwd -P)"
export PROJECT_ROOT
# 调用子脚本
./scripts/backup.sh
# ----------------------------------
# backup.sh
# 读取 main.sh 导出的路径
cd "$PROJECT_ROOT" || exit 1
echo "当前在: $(pwd -P)"
./scripts/do_backup.sh
用 pwd -P 加上 export 传递路径，比每次重新计算靠谱得多。
场景四：crontab 任务中的路径问题
crontab 的执行环境跟你手动敲命令完全不一样，它的 cwd 通常是用户的家目录。
# 错误写法（在crontab里）
* * * * * ./script.sh
# 正确写法：先cd再执行
* * * * * cd /data/app && ./script.sh
# 更稳妥：在脚本里自己确定目录
* * * * * /data/app/script.sh
脚本开头用 cd "$(dirname "$0")" 切到脚本所在目录，然后用 pwd -P 确认。这样即使 crontab 环境诡异也不怕。
今日作业
建一个测试场景：
1. 创建一个真实目录 /tmp/real_dir
2. 创建一个软链接 ln -s /tmp/real_dir /tmp/link_dir
3. 分别用 cd /tmp/link_dir 和 cd -P /tmp/link_dir 进入
4. 各执行一次 pwd 和 pwd -P
看看输出有什么不同？然后说说 readlink -f 和 pwd -P 返回的结果是不是一样。
10个月宝宝每天需要喝多少奶粉？