企业官网建设流程全解析

简介：这份《linux命令手册》是面向Linux新手与系统管理员的重要参考资料，聚焦命令行界面下的高频操作与系统维护场景。手册以系统管理命令为主线，依次讲解用户账户添加与删除、用户组修改、登录Shell切换、系统时间设置与关机操作等基础内容，并延伸至文件与目录操作、权限管理、网络配置、软件安装及进程控制等常见运维模块，覆盖从身份查询到系统状态监控的完整命令链条。资源打包为1.46MB的单个PDF文件，文件总数仅1个，轻量易存，适合放在桌面或移动设备中随时离线查阅。目前已有2091人学习下载，无论是刚开始接触命令行的初学者，还是需要快速查找参数的系统管理员，都可以借助这份手册提升在Linux环境下的操作效率，减少记忆负担。

1. 与其收藏别人的 linux命令手册.pdf，不如自己生成一份

很多同学电脑里都躺着一份网上下载的 linux命令手册.pdf，几百页，覆盖几百条命令。但真到线上出故障、需要紧急查参数时，你翻三分钟也找不到那一行，因为别人的整理逻辑和你当下的问题对不上。做过几年运维和后台开发的人，最后往往会把这种「收藏向」的 PDF 扔掉，改成自己按需生成一份：直接基于系统自带的 man 文档转成 PDF，再按自己的高频场景做索引。这套做法更快、更准，还不怕版本过时。这篇文章就围绕「linux命令手册.pdf 怎么来、怎么背、怎么用、哪里会翻车」展开，面向已经把 Linux 当日常工作环境、但对 man 体系还不熟的从业者，以及想给团队沉淀一份内部速查手册的开发者。理论就一句——手册最好的来源是你系统里已经装好的那份，不用重新发明。

2. 真正的手册源头：man pages 里藏着每个命令的最终答案

2.1 为什么先捣鼓 man pages，而不是直接搜网上的「linux命令手册.pdf」

网上流传的 linux命令手册.pdf 有个致命问题：版本漂移。你在 CentOS 7 上查到的yum参数表，和 Ubuntu 22.04 的apt手册完全是两套行为逻辑；tar、find、grep这些命令在不同发行版、不同 coreutils 版本里的默认行为和选项差异也足够让你在脚本里踩坑。而你的机器上已经装了配套版本的 man 文档，它和二进制来自同一个包，描述的一定是当前这台机器真实的行为。

另一个问题是覆盖范围。网上现成的手册往往只挑高频命令，但你在真实工作中遇到的偏偏是冷门场景：systemctl的--failed、journalctl的-k -b -1、ip命令的ip addr add和ip route的完整格式。man pages 按章节组织，从用户命令（第 1 章）到系统调用（第 2 章）再到配置文件格式（第 5 章），你的问题几乎都能在里面找到原文。与其依赖一份整理者的二手转述，不如直接读系统给你的第一手文档。

还有一个常被忽略的点：man pages 会随软件包更新。你升级了 nginx、openssl 或者核心工具包，man 文档也会跟着变。这意味着你每次生成 PDF 时，内容和当前系统的行为是强一致的。用这份材料做速查表，不会有「手册说可以这么写，但实际跑不通」的尴尬。所以请把「下载别人的手册」这个习惯改成「自己从 man 导出」，这才是这份工作流真正的起点。

2.2 先学会翻阅：三分钟解锁 man 的正确姿势

在动手转 PDF 之前，先把 man 本身的交互玩熟。很多人对 man 的印象停留在「打开以后用方向键翻页，按 q 退出」，这个认知足够看手册，但不足以高效抽取内容。man 的底层是less分页器，因此所有 less 的搜索能力都能用。

阅读时最常用的三个操作：按/输入关键词做向下搜索，按?向上搜索，按n跳到下一个匹配。你要查rsync的--delete选项，直接/--delete，不要从头翻到最后。还有两个容易被忽略的快捷键：g回到文件头部，G跳到文件末尾。某些版本的 man 在终端宽度不够时会自动折行，你可以用man --width=200强制按 200 列宽显示，导出的文本或 PDF 会宽很多，排版也更舒服。

如果你想把某条命令的文档快速拉出来处理，还可以这样用：

man ls | col -b > ls_man.txt

这条命令的逻辑是：man ls输出带退格符和特殊控制字符的原始格式文本，col -b把这些控制字符过滤掉，生成一份干净的纯文本。后面我们要做批量整理时，这种干净文本就是素材。注意col -b是 BSD 工具，绝大多数 Linux 发行版都自带，不用额外安装。

man 还支持按章节精确查找。比如man 5 crontab看的是crontab配置文件的格式说明，而不是man 1 crontab的命令用法。这个差异很关键：当你写定时任务时真正需要的是第 5 章的格式定义。熟练使用章节参数，是脱离「幼儿级翻手册」的第一步。

2.3 你得知道 man 的章节编号，才能按图索骥

man 按章节编号组织，常见的章节如下：

查命令时养成习惯：先想它属于哪一章。man useradd和man 8 useradd大概率指向同一个文档，但man passwd会优先展示第 1 章的命令文档，而man 5 passwd展示的是/etc/passwd文件的字段说明。这就是为什么有人在配置里改了/etc/passwd后想确认字段含义，直接man passwd翻半天没找到重点——他需要的是man 5 passwd。

用man -w可以查看某个命令在哪些章节存在：

man -w passwd

/usr/share/man/man1/passwd.1.gz /usr/share/man/man5/passwd.5.gz

输出显示两个文件都存在。看到.1.gz和.5.gz这两个后缀，就知道这份文档分别属于命令类与配置文件类。这个信息在批量导出时非常有用：你完全可以只挑第 1 章和第 8 章的命令来生成一份「日常操作手册」，把写库函数、查驱动的章节留给真正需要的人。

3. 把 man 变成可以随时翻阅的 PDF：从单条命令到整库导出

3.1 最小可用的转化链路：man -t 加 ps2pdf

把 man 转成 PDF 的常见做法是用man -t输出 PostScript 排版结果，再交给ps2pdf二次转换。man -t内部会调用groff（GNU 排版系统），按-Tps参数输出 PostScript 格式，然后通过管道传给 Ghostscript 提供的ps2pdf，就得到一份带基础排版、可搜索的 PDF。

先试一条命令：

man -t ls | ps2pdf - ls.pdf

如果这条路顺畅，当前目录会出现一个ls.pdf。这里ps2pdf -的-表示从标准输入读取 PostScript 数据，ls.pdf是输出文件名。逻辑链路是：man 把 ls 的手册内容交给 groff 渲染成 PostScript 排版流，ps2pdf 再把它封装成 PDF 文件。

多数情况下你还需要一个中间步骤：直接转 PDF 报错不好定位，先转成 PostScript 看是否正常。man -t ls > ls.ps，然后用 evince、Okular 或gs查看这个 PS 文件，如果 PS 能正常显示而 PDF 是坏的，问题多半出在 Ghostscript 这边；如果 PS 本身就是乱码，那问题在 man/groff 的字体配置上。这个拆分排查习惯能帮你快速定位翻车点。

man -t还支持同时传多条命令，但混合章节时要注意命令名冲突。man -t passwd crontab会把第一个匹配到的passwd排出，如果你想明确指定章节，可以写man -t 5 passwd 5 crontab。只是平时一条命令一条 PDF 更清晰，便于归档和检索。

3.2 统一批量导出：把 bin 目录里的命令变成一套手册

单条命令转换没问题后，接下来做批量导出。目标是跑一个脚本，把当前机器上你常用的命令全部转成 PDF，并按命令名命名。常见做法是用compgen -c收集 shell 里所有可执行的命令名，再逐个试探 man 是否存在。

#!/bin/bash # 批量导出常见命令的 man 手册 # 用法: ./export_man_pdf.sh /output/dir OUT_DIR="${1:-./man_pdfs}" mkdir -p "$OUT_DIR" # 取系统已有命令列表，去重后遍历 cmds=$(compgen -c | sort -u) for cmd in $cmds; do # 只处理存在文档的命令；man -w 能找到就转 if man -w "$cmd" >/dev/null 2>&1; then man -t "$cmd" 2>/dev/null | ps2pdf - "$OUT_DIR/${cmd}.pdf" # 留意文件大小过小，通常说明转换过程出错 if [ -s "$OUT_DIR/${cmd}.pdf" ]; then echo "OK: $cmd" else rm -f "$OUT_DIR/${cmd}.pdf" echo "SKIP: $cmd (empty pdf)" fi fi done

这里compgen -c是 bash 的内置补全函数，会列出当前环境认识的所有命令名，包括 shell 内建命令、别名和 PATH 下的可执行文件。man -w在前面已经见过，用来确认是否存在对应手册。>/dev/null 2>&1把正常输出和错误都丢弃，只保留退出状态码，避免找不到文档时刷屏。

ps2pdf生成空文件的原因多半是man -t对个别命令的特殊排版出错，比如某些脚本类命令没有真正的 man 文档，man 会显示一段默认提示，转出来的 PDF 几乎没有内容。脚本里用[ -s file ]检查文件非空，顺手把空文件删掉，这类「假成功」的 PDF 就不会混进你的手册库。为了控制运行时间，建议先用compgen -c | head -50试小批，再放全量。

导出完成之后，可以把所有 PDF 合并成一个「大厚本」，用pdfunite或qpdf都能做：

pdfunite $(ls ${OUT_DIR}/*.pdf | sort) linux命令手册.pdf

pdfunite的输入按你给的顺序拼接，不保证按字母序，所以先用sort排序。合并完再检查文件整体大小，如果出现某个命令的 PDF 异常巨大，单独把它抽出来看看，别让一个失控的排版拖垮整份文档。

3.3 中文字体与排版：让生成的手册能看懂

国内环境的 Linux 一般默认 locale 是zh_CN.UTF-8，但groff默认字体表里并没有中文。直接在中文语言环境下man -t，生成的 PDF 里中文字符经常变成空白或方块，这是最典型的翻车现场。解决路径是给 groff 配置好中文字体，并且在转 PDF 前把 locale 切到C或C.UTF-8，强制 man 输出英文文本。

export LC_ALL=C man -t ls | ps2pdf - ls_cn_test.pdf

切到Clocale 后，man 的内容全部回退成英文，绕开 groff 的 CJK 字体问题。如果一定要保留中文本地化的手册文本，需要确认系统里装了groff的 CJK 支持包，并且设置groff的字体映射。多数发行版默认没配好，为了稳定产出，建议直接用英文文本，命令行的核心技能点都在参数和选项上，英文障碍远没有想象中大。

另外一个容易被忽略的排版问题：终端宽度影响 man 输出行宽。man -t生成的 PostScript 默认按 80 列排版，如果你的命令选项特别长，说明文字会被截断。用--width参数加大宽度：

man --width=200 -t rsync | ps2pdf - rsync.pdf

这样 rsync 的--delete-after这类长参数说明不会折行折得乱七八糟。同样的逻辑，在批量导出脚本里建议统一加--width=200，让所有 PDF 的排版风格一致。

4. 导出过程中的经典排查：这几个坑几乎每个人都会踩

4.1 现象：PDF 打开后全是方块和乱码

原因：locale 是zh_CN.UTF-8，man 输出中文，但 groff 的默认字体路线不支持 CJK，最终 PDF 里中文字符映射不到字形。

解决：导出前显式切换到英文环境。写进脚本时可以用：

export LC_ALL=C

如果不想影响当前 shell 的 locale，可以在命令前面加env LC_ALL=C man -t ls | ps2pdf - ls.pdf。这个env LC_ALL=C只在单条命令生效，不会污染终端里的其他行为。

4.2 现象：导出没任何报错，但生成的是空 PDF 或只有一页空白

原因：man -t对某些命令找不到文档，输出了一段「没有手册页」的默认提示；或者 groff 排版中途失败，但错误被管道吞掉了。你只检查了退出状态码，没检查 PDF 的实际内容。

解决：转换前先用man -w判断文档是否存在，转换后检查 PDF 文件大小，低于 10KB 的基本可以视为空壳。批量脚本里要同时做这两层判断。更稳妥的做法是用groff -Tpdf直接转，绕过 man 对不存在文档的回退行为。

4.3 现象：man -t 在终端屏幕刷出一大堆乱码和转义字符

原因：man -t的输出是 PostScript 排版代码，设计给打印或转 PDF 用的，不是给人直接看的。直接在终端不带管道执行，就会看到满屏%!PS-Adobe-3.0和一堆转义指令。

解决：man -t必须配合管道使用。这条命令的正确姿势是man -t 命令名 | ps2pdf - 输出.pdf，输出永远走管道，不要裸奔在终端里。这个现象本身不是 bug，只是参数语义没理解透。

4.4 现象：同样的命令，换一台机器导出的 PDF 内容和选项不一样

原因：每台机器上命令版本不同，man 文档版本自然也不同。比如ls在 coreutils 8.x 和 9.x 之间就有行为差异；某些发行版会额外打补丁，新增自定义选项并更新 man 文档。

解决：这份 PDF 只对导出它的那台机器负责。如果需要在多台机器之间共享手册，先约定统一的操作系统版本和应用版本；否则你会发现 A 机的手册写着支持--time-style=long-iso，B 机的真实命令却不认。线上排查时永远以目标机器的实际文档为准。

4.5 现象：手册里的某个选项查不到，但网上明明有人用过

原因：你搜到的用法来自不同版本的软件或发行版额外补丁，目标机器的软件版本没这个功能；也有些选项藏在别的命令里，比如ps的-e和ax在各版本下的语义不同，man 文档里只写了当前版本的实现。

解决：先确认man出来的版本信息，用命令名 --version和man -w 命令名交叉验证。如果确认版本没问题，再去查这个命令的官方发布说明或包管理器的 changelog，看新老版本的选项增删记录。这种「网上有、本机没有」的情况，九成是版本差异，不是文档缺失。

5. 从 PDF 到真正会用的手册：沉淀自己的高频命令速查页

5.1 基于实际历史记录，做一份只有 30 条命令的速查清单

很多人拿着几百页的 linux命令手册.pdf 却不知道该背什么，因为那是给别人写的通用手册，不是给你写的。我自己的习惯是：导出全量 PDF 后并不背它，而是从 shell 历史里统计真正高频的命令，把命中率最高的 30 到 50 条单独抽出来，做成 2 到 3 页的速查页。每一条包含功能、参数、一个实际使用的例子。

# 统计历史命令中出现次数最多的前 40 个命令 history 5000 | awk '{print $2}' | sort | uniq -c | sort -rn | head -40

逻辑解析：history 5000读取最近 5000 条历史命令，awk '{print $2}'取每行的第二个字段（即命令名），sort | uniq -c计数后按出现次数降序排列，最后取前 40。这个统计结果会非常出乎意料——你以为自己天天用vim，结果排行第一的可能是cd、ls和git status，这才是你真实的工作热点。

把这份清单作为速查页的第一部分，然后从「故障场景」出发补三个固定分类：磁盘与 inode 查看（df、du、lsblk）、进程与端口排查（ps、ss、lsof、kill）、日志与启动项分析（journalctl、systemctl、dmesg）。这三类问题在线上出现频率最高，速查页里每类控制在 8 条以内，每条一句注释，用最精简的方式记录「怎么查、关键参数是什么、常见坑是什么」。

5.2 把速查页转成 PDF，编进你的 linux命令手册.pdf 开头

速查页的载体，我推荐用 Markdown 维护，再转成 PDF 放进手册开头。这样做的好处是速查页更新成本极低，你发现某个参数记错了或者版本变更了，改一行 Markdown 重新转一遍就行，不用动几百页的完整手册。转换工具用pandoc配合 LaTeX 引擎，或者直接用md-to-pdf这类工具。

pandoc cheatsheet.md -o cheatsheet.pdf --pdf-engine=xelatex -V CJKmainfont="Noto Sans CJK SC"

--pdf-engine=xelatex指定用 XeLaTeX 处理字体与 Unicode，-V CJKmainfont指定中文主字体为 Noto Sans CJK SC。如果你的系统没装该字体，先fc-list | grep -i noto查看本机可用字体再替换。整条命令的作用就是确保速查页里的中文能正常渲染，不会重演第 4 章那个乱码问题。

最后把速查页合并到全量手册前面，用pdfunite cheatsheet.pdf linux命令手册.pdf final_manual.pdf，让整份手册形成「速查卡在前、全量文档在后」的结构。日常工作时只看速查卡那几页，遇到速查卡覆盖不上的冷门场景再翻全量 PDF，效率比直接抱着几百页啃高得多。

5.3 让这份手册成为团队协作的中间层

如果你负责的小团队有好几台相同配置的服务器，手动在每台机器上导出 PDF 是浪费时间。常见做法是把导出脚本和速查页 Markdown 收进版本库，配上固定的操作系统镜像版本。新机器上线时自动执行一次导出和合并，生成的 linux命令手册.pdf 由 CI 产物归档，人人可下载。这样团队面对的永远是「这台机器自己生成的文档」，而不是某个人三个月前导出的过期版本。

真正值得花时间的，是维护那份 30 条命令的速查页。每处理完一次线上故障，就把这次用到的高频参数和踩坑点更新进去。两个月后你会发现，整份 PDF 最薄的那几页反而是价值密度最高的部分。我自己就是把「排查磁盘满」「排查端口冲突」「看上次重启后的内核日志」这三类方法固化进速查页，后来的类似问题基本靠这几页就解决了。如果你只是收藏了一份别人的 linux命令手册.pdf，它躺在硬盘里和不存在没有区别；但如果你能维护起一套「系统自动生成 + 个人高频速查」的文档流，这份手册才真正开始为你工作。希望这篇笔记能帮到你，也祝你的手册永不蒙灰。

本文还有配套的精品资源，点击获取