Linux pathchk 怎样检查文件名的可移植性

如果构建脚本要把文件名交给不同的 POSIX 主机、归档工具或发布流水线，先用 pathchk 检查名字，比等到复制或解包阶段才发现不兼容更稳妥。最常用的结论是：pathchk -p 检查 POSIX 可移植字符集和最小长度，pathchk -P 额外检查空名及以 - 开头的路径分量，pathchk --portability 则把两组规则合并。

官方文档：https://www.gnu.org/s/coreutils/manual/html_node/pathchk-invocation.html

先分清默认检查与可移植性检查

排查文件名问题时，最容易混淆的是“当前机器能不能处理”和“换到其他 POSIX 主机后仍然稳不稳”。不带选项运行 pathchk，重点是当前环境：路径中已经存在的目录需要有搜索（执行）权限，完整名称不能超过操作系统支持的长度，已经存在的目录分量也不能超过文件系统允许的单个名称长度。

这意味着，一个尚不存在的目标文件并不因为“不存在”而自动失败。只要按默认检查所依据的条件，它未来可以被创建，pathchk 就不会把“尚不存在”本身当成错误。若目标是跨机器交换，应该显式切换到 -p 或 --portability，不要把本机通过当成便携性证明。

用 -p 检查 POSIX 名称集合与最小长度

-p 的重点不是判断文件已经创建，而是把名字放进更保守的可移植规则里。GNU Coreutils 手册列出的便携文件名字符集包括 ASCII 字母和数字、点号、下划线、连字符以及路径分隔符 /。名称或任一路径分量超过 POSIX 的最小长度限制，也会被报告。

例如归档入口可以先做一次单独检查。下面的命令块展示的是脚本写法，注释说明参数和退出码含义；它不把示例输出当成某台机器上的运行截图。

#!/usr/bin/env bash
set -u

name="$1"

# -p 只按 POSIX 可移植规则检查名字，不把本机文件系统的宽松程度当作兼容性证明。
if pathchk -p -- "$name"; then
  # 退出码 0 表示这个输入通过了 -p 的全部检查。
  printf 'portable-name: %s\n' "$name"
else
  # 退出码 1 表示名称不满足至少一项可移植性条件。
  printf 'not-portable-name: %s\n' "$name" >&2
  exit 1
fi

这里的 -- 是 shell 命令调用中的参数边界，避免把后续输入误当成选项；真正决定 POSIX 便携性的规则仍由 -p 执行。对于可能包含空格或通配符的输入，双引号也不能省略，否则还没进入 pathchk 就可能先被 shell 拆分或展开。

用 -P 处理以连字符开头的路径分量

-P 和 -p 解决的是不同问题。它会在名称为空，或者某个路径分量以 - 开头时报告错误。后一条规则适合提醒脚本作者：即使一个名称在字符集和长度上没有问题，进入后续命令时仍可能产生参数解析歧义。

比如 archive/-draft/report.txt 的问题不在于斜杠后的字符串含有非法字符，而在于中间分量 -draft 具有容易被命令行当作选项的形态。把 -P 视为“脚本入口的命名边界”更准确，它不是对权限、文件内容或归档格式的检查。

#!/usr/bin/env bash
set -u

candidate="$1"

# -P 检查空名以及每个路径分量是否以连字符开头，补上脚本参数边界检查。
if ! pathchk -P -- "$candidate"; then
  # 失败只说明命名规则不满足，不代表文件本身已经损坏。
  printf 'unsafe-path-component: %s\n' "$candidate" >&2
  exit 1
fi

# 通过后再交给后续归档或构建步骤，避免把命名问题拖到更晚阶段。
printf 'accepted-path-component: %s\n' "$candidate"

如果你的跨平台约束还包括字符集和长度，就不要只调用 -P，而应使用 -p -P 或更直观的 --portability。这两个选项的职责可以叠加，但不能互相替代。

按脚本入口组合检查并读取退出码

批量生成归档名时，可以把完整检查集中在一个入口。--portability 等价于 -p -P，既覆盖 POSIX 可移植字符集和最小长度，也覆盖空名与连字符开头的分量。多个名称可以作为多个操作数传给同一次调用；只要有一个没有通过，整体就应按失败处理。

#!/usr/bin/env bash
set -u

# 这些名称来自待归档清单；数组能保留包含空格的单个名称边界。
names=("release-2026/app.tar" "docs/user-guide.txt")

# --portability 等价于 -p -P，适合把跨 POSIX 交换的命名规则集中检查。
if pathchk --portability -- "${names[@]}"; then
  # 所有操作数都通过时才继续生成归档或发布清单。
  printf '%s\n' 'all names passed portability checks'
else
  # 非零退出码表示至少一个输入失败，应该停止后续的不可逆步骤。
  printf '%s\n' 'at least one name failed portability checks' >&2
  exit 1
fi

这里要特别留意两个判断边界。第一，pathchk 的退出码只告诉你输入是否通过所选规则，成功不是“文件已经创建”的同义词。第二，若输入来自外部清单，先在 shell 中保持参数为独立元素，再交给 pathchk；不要把整串名称拼成一段未加引号的文本。

补上 pathchk 不负责的存在性与写入性判断

pathchk 适合做名称边界检查，但它不是完整的文件创建预检器。默认模式会涉及已有目录的搜索权限，仍然不等于后续写入操作一定成功；-p 与 -P 更是专门围绕名称可移植性。磁盘空间、配额、目标挂载点、实际创建时的竞态以及归档工具自身规则，都要由后续步骤处理。

可以把一次稳妥的流水线拆成三层：先用 pathchk --portability 约束名字，再用真正的创建或打包动作处理文件系统结果，最后在目标主机或解包环境做一次针对性回归。这样既不会因为本机文件系统更宽松而放过跨主机风险，也不会把名称检查夸大成写入保证。

常见问题

-p 和 --portability 有什么区别？

-p 只做 POSIX 可移植字符集和最小长度相关检查；--portability 等价于 -p -P，还会检查空名和以连字符开头的路径分量。

pathchk 通过后，目标文件一定存在吗？

不一定。一个不存在的名字只要在相应条件下可以被创建，就不因“不存在”本身报错。是否存在、是否可写，应由后续文件操作判断。

为什么脚本里还要保留 --？

-- 用来明确告诉命令后面是操作数，避免名字本身以连字符开头时被解析成选项。它和 -P 的职责不同：前者是调用时的参数边界，后者是对名字规则的检查。

实际落地时，可以按“先决定目标环境—再选默认、-p、-P 或组合—最后处理真实创建结果”的顺序使用 pathchk。这样检查结果的含义更清楚，也不会把一个小型命名工具当成完整的部署验收。