每天学一个Linux命令系列(3):pwd - 连pwd都有坑?软链接让你迷路

这个命令是干啥的

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 返回的结果是不是一样。