POSIX，你肯定在各种在线论坛和文章中，听到过这个缩写，或读到过关于它的信息。程序员和系统开发人员似乎最关心这个问题。它听起来很神秘，虽然有很多关于这个主题的好资料，但一些讨论区（简洁是它们的特点）并没有详细说明它是什么，这可能会让人困扰。那么，POSIX 到底是什么？

POSIX 简介

与其说 POSIX 是一个东西，不如说是一个标签。想象一下，有一个盒子，上面贴着标签：POSIX，而盒子里是一个标准。该标准由 POSIX 所关注的规则和指令集组成。POSIX 是 可移植操作系统接口 Portable Operating System Interface 的缩写。它是一个 IEEE 1003.1 标准，其定义了应用程序（以及命令行 Shell 和实用程序接口）和 UNIX 操作系统之间的语言接口。

当 UNIX 程序从一个 UNIX 平台移植到另一个平台时，遵守该标准可以确保其兼容性。POSIX 主要关注的是 AT&T 的 System V UNIX 和 BSD UNIX 的特性。

该标准必须阐明并遵循如何实现操作系统之间互操作性的目标的规则。POSIX 涵盖了以下内容：系统接口、命令和实用程序、网络文件访问，这里仅举几例（POSIX 的内容远不止这些）。

为什么有 POSIX？

一句话：可移植性。

60 多年前，如果程序员想让他们的软件在一个以上的系统上运行，就必须完全重写代码。由于所涉及的费用，这种情况并不经常发生，但在 1960 年代中期，可移植性成为一种特性 —— 不是通过 POSIX，而是在大型机领域。

IBM 推出了 System/360 系列的大型计算机。不同的型号有其独特的规范，但硬件使得它们可以使用同一个操作系统：OS/360。

不仅操作系统可以在不同的型号上运行，应用程序也可以在它们上面运行。这不仅降低了成本，而且创造了“计算机系统”：可以跨产品线协同工作的系统。今天，这一切都很常见，比如网络和系统，但在当时，这是一个巨大的进步！

大约在同一时间，当 UNIX 出现的时候，它也做出了承诺，它可以在不同制造商的机器上运行。然而，当 UNIX 开始衍生出不同的流派时，在这些 UNIX 变体之间移植代码变得很困难。UNIX 可移植性的承诺正在失去基础。

为了解决这个可移植性问题，在 20 世纪 80 年代形成了 POSIX 标准。这个标准是在 AT&T 的 System V UNIX 和 BSD UNIX 的基础上定义的，这是当时最大的两个 UNIX 变体。值得注意的是，POSIX 的形成并不是为了控制操作系统的构建方式，任何公司都可以自由地以他们喜欢的方式设计他们的 UNIX 变体。POSIX 只关心应用程序与操作系统的接口是怎样的。用程序员的话来说，接口是一个程序的代码与另一个程序的通信方法。接口期望程序 A 向程序 B 提供特定类型的信息。同样地，程序 A 期望程序 B 用特定类型的数据来回答。

例如，如果我想用 cat 命令读取一个文件，我会在命令行上输入类似这样的内容：

cat myfile.txt

我不想说很多程序员的术语，简单的来说，cat 命令调用操作系统来获取文件，以便 cat 能够读取它。cat 读取它，然后在屏幕上显示文件的内容。在应用程序（cat）和操作系统之间有很多的相互作用。这种相互作用如何工作是 POSIX 所关心的。如果这种相互作用在不同的 UNIX 变体中是相同的，那么可移植性，无论操作系统、制造商和硬件如何，就可以重新获得了。

关于如何实现这一切的具体细节，在该标准中作了规定。

合规是自愿的

我们所有人都至少见过这样的信息：“如需帮助，请输入：XXXX -help”。这在 Linux 中很常见，但是这不符合 POSIX 标准。POSIX 从来没有要求双破折号，他们希望用一个破折号。双破折号来自 GNU，然而，它并没有损害 Linux，而且还为其增加了一点特性。同时，Linux 大部分都是兼容 POSIX 的，特别是在涉及到系统调用接口时。这就是为什么我们能够在 Linux、Sys V UNIX 和 BSD UNIX 上运行 X、GNOME 和 KDE 应用程序。各种命令，如 ls、cat、grep、find、awk 等，在不同的变体中操作相同。

作为一项规则，合规是一个自愿的步骤。当代码符合要求时，移到另一个系统上就比较容易，很少有必要或根本不需要重写代码。当代码可以在不同的系统上工作时，它的使用范围就会扩大。使用其他系统的人可以从使用该程序中受益。对于初出茅庐的程序员来说，学习如何编写符合 POSIX 标准的程序，就能对他们的职业生涯有所帮助。对于那些对 Linux 领域的合规性感兴趣的读者，可以在以下网站找到很多好的信息： Linux 基本标准（LSB）。

但我不是程序员或系统设计师...

许多从事计算机工作的人并不是程序员或操作系统设计师。他们是医院的文员，是写信件、任务清单、听写备忘录的秘书，等等。其他人则是将数字制成表格，收集和整理数据，经营网上商店，写书和文章（我们中的一些人还会阅读这些文章）。几乎在每一个工作中，附近都可能有一台计算机。

POSIX 也影响着这些用户，不管他们是否知道。用户不一定要遵守这个标准，但他们确实希望他们的计算机能够工作。当操作系统和程序符合 POSIX 标准时，他们就获得了互操作性的好处。他们将能够从一个系统转移到另一个系统，并合理地期望这些机器能够像另一个系统那样工作。他们的数据仍然可以访问，他们仍然能够对其进行修改。

POSIX，以及其他标准，都在不断发展。随着技术的发展，标准也在发展。标准实际上是人们、制造商、组织等用来以有效的方式执行任务的商定系统。一个制造商的设备能够与另一个制造商的设备一起工作。想一想吧。你的蓝牙耳机可以在苹果手机上使用，也可以在安卓手机上使用。我们的电视可以连接到不同网络的视频和节目，如 Amazon Prime、BritBox、Hulu —— 仅举几例。现在，我们甚至可以用我们的手机监测心率。所有这些在很大程度上都是通过遵守标准而实现的。

好处多多。我喜欢这样。

那么 “X” 是什么？

我承认，我还没说过 POSIX 中的 “X” 是什么意思。在一篇很好的文章中，Richard Stallman 解释了 POSIX 中的 “X” 是什么意思。用他的话来说就是这样：

IEEE 已经完成了规范的制定，但没有简洁的名称。标题是 “可移植的操作系统接口”，虽然我不记得确切的字眼了。委员会把 “IEEEIX” 作为简写。我不认为这是个好的选择。它的发音很难听 —— 听起来就像恐怖的尖叫声，“Ayeee！” —— 所以我预计人们会把这个规范叫为 “Unix”。

由于 GNU 不是 Unix，而它的目的是取代 Unix，我不希望人们把 GNU 称为 “Unix 系统”。因此，我提出了一个人们可能真正使用的简洁的名字。在没有特别灵感的情况下，我用了一种很笨的方式取了一个名字。我取了 “可移植操作系统” 的首字母并加上 “ix”。IEEE 马上就采用了这个名字。

结论

POSIX 标准允许开发者使用大部分相同的代码在许多操作系统上创建应用程序、工具和平台。不管怎么说，按照标准写代码并不是一个要求，但当你想把你的代码移植到其他系统时，它确实有很大的帮助。

基本上，POSIX 是面向操作系统设计者和软件开发者的，但作为系统的使用者，无论我们是否意识到，我们都受到 POSIX 的影响。正是因为有了这个标准，我们才能够在一个 UNIX 或 Linux 系统上工作，并把工作带到另一个系统上，而且工作起来毫无障碍。作为用户，我们在可用性和跨系统的数据重复使用方面获得了许多好处。

via: https://itsfoss.com/posix/

作者：Bill Dyer 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

从计算机自由先驱的口中探寻操作系统兼容性标准背后的本质。

POSIX 是什么？为什么如此重要？你可能在很多的技术类文章中看到这个术语，但往往会在探寻其本质时迷失在 技术初始主义 techno-initialisms 的海洋或是 以 X 结尾的行话 jargon-that-ends-in-X 中。我给 Richard Stallman 博士（在黑客圈里面常称之为 RMS）发了邮件以探寻这个术语的起源及其背后的概念。

Richard Stallman 认为用 “开源” 和 “闭源” 来归类软件是一种错误的方法。Stallman 将程序分类为 尊重自由的 freedom-respecting （“ 自由 free ” 或 “ 自由（西语） libre ”）和 践踏自由的 freedom-trampling （“ 非自由 non-free ” 或 “ 专有 proprietary ”）。开源讨论通常会为了（用户）实际得到的 优势/便利 advantages 考虑去鼓励某些做法，而非作为道德层面上的约束。

Stallman 在由其本人于 1984 年发起的 自由软件运动 The free software movement 表明，不仅仅是这些 优势/便利 advantages 受到了威胁。计算机的用户 理应得到 deserve 计算机的控制权，因此拒绝被用户控制的程序即是 非正义 injustice ，理应被 拒绝 rejected 和 排斥 eliminated 。对于用户的控制权，程序应当给予用户 四项基本自由：

• 自由度 0：无论用户出于何种目的，必须可以按照用户意愿，自由地运行该软件。
• 自由度 1：用户可以自由地学习并修改该软件，以便按照自己的意愿进行计算。作为前提，用户必须可以访问到该软件的源代码。
• 自由度 2：用户可以自由地分发该软件的副本，以便可以帮助他人。
• 自由度 3：用户可以自由地分发该软件修改后的副本。借此，你可以让整个社区受益于你的改进。作为前提，用户必须可以访问到该软件的源代码。

关于 POSIX

Seth: POSIX 标准是由 IEEE 发布，用于描述 “ 可移植操作系统 portable operating system ” 的文档。只要开发人员编写符合此描述的程序，他们生产的便是符合 POSIX 的程序。在科技行业，我们称之为 “ 规范 specification ” 或将其简写为 “spec”。就技术用语而言，这是可以理解的，但我们不禁要问是什么使操作系统 “可移植”？

RMS: 我认为是 接口 interface 应该（在不同系统之间）是可移植的，而非任何一种系统。实际上，内部构造不同的各种系统都支持部分的 POSIX 接口规范。

Seth: 因此，如果两个系统皆具有符合 POSIX 的程序，那么它们便可以彼此假设，从而知道如何相互 “交谈”。我了解到 “POSIX” 这个简称是你想出来的。那你是怎么想出来的呢？它是如何就被 IEEE 采纳了呢？

RMS: IEEE 已经完成了规范的开发，但还没为其想好简练的名称。标题类似是 “可移植操作系统接口”，虽然我已记不清确切的单词。委员会倾向于将 “IEEEIX” 作为简称。而我认为那不太好。发音有点怪 - 听起来像恐怖的尖叫，“Ayeee！” - 所以我觉得人们反而会倾向于称之为 “Unix”。

但是，由于 GNU 并不是 Unix GNU’s Not Unix ，并且它打算取代之，我不希望人们将 GNU 称为 “Unix 系统”。因此，我提出了人们可能会实际使用的简称。那个时候也没有什么灵感，我就用了一个并不是非常聪明的方式创造了这个简称：我使用了 “ 可移植操作系统 （ portable operating system ） ” 的首字母缩写，并在末尾添加了 “ix” 作为简称。IEEE 也欣然接受了。

Seth: POSIX 缩写中的 “操作系统” 是仅涉及 Unix 和类 Unix 的系统（如 GNU）呢？还是意图包含所有操作系统？

RMS: 术语 “操作系统” 抽象地说，涵盖了完全不像 Unix 的系统、完全和 POSIX 规范无关的系统。但是，POSIX 规范适用于大量类 Unix 系统；也只有这样的系统才适合 POSIX 规范。

Seth: 你是否参与审核或更新当前版本的 POSIX 标准？

RMS: 现在不了。

Seth: GNU Autotools 工具链可以使应用程序更容易移植，至少在构建和安装时如此。所以可以认为 Autotools 是构建可移植基础设施的重要一环吗？

RMS: 是的，因为即使在遵循 POSIX 的系统中，也存在着诸多差异。而 Autotools 可以使程序更容易适应这些差异。顺带一提，如果有人想助力 Autotools 的开发，可以发邮件联系我。

Seth: 我想，当 GNU 刚刚开始让人们意识到一个非 Unix 的系统可以从专有的技术中解放出来的时候，关于自由软件如何协作方面，这其间一定存在一些空白区域吧。

RMS: 我不认为有任何空白或不确定性。我只是照着 BSD 的接口写而已。

Seth: 一些 GNU 应用程序符合 POSIX 标准，而另一些 GNU 应用程序的 GNU 特定的功能，要么不在 POSIX 规范中，要么缺少该规范要求的功能。对于 GNU 应用程序 POSIX 合规性有多重要？

RMS: 遵循标准对于利于用户的程度很重要。我们不将标准视为权威，而是且将其作为可能有用的指南来遵循。因此，我们谈论的是 遵循 following 标准而不是“ 遵守 complying ”。可以参考 GNU 编码标准 GNU Coding Standards 中的 非 GNU 标准 段落。

我们努力在大多数问题上与标准兼容，因为在大多数的问题上这最有利于用户。但也偶有例外。

例如，POSIX 指定某些实用程序以 512 字节为单位测量磁盘空间。我要求委员会将其改为 1K，但被拒绝了，说是有个 官僚主义的规则 bureaucratic rule 强迫选用 512。我不记得有多少人试图争辩说，用户会对这个决定感到满意的。

由于 GNU 在用户的 自由 freedom 之后的第二优先级，是用户的 便利 convenience ，我们使 GNU 程序以默认 1K 为单位按块测量磁盘空间。

然而，为了防止竞争对手利用这点给 GNU 安上 “ 不合规 noncompliant ” 的骂名，我们实现了遵循 POSIX 和 ISO C 的可选模式，这种妥协着实可笑。想要遵循 POSIX，只需设置环境变量 POSIXLY_CORRECT，即可使程序符合 POSIX 以 512 字节为单位列出磁盘空间。如果有人知道实际使用 POSIXLY_CORRECT 或者 GCC 中对应的 --pedantic 会为某些用户提供什么实际好处的话，请务必告诉我。

Seth: 符合 POSIX 标准的自由软件项目是否更容易移植到其他类 Unix 系统？

RMS: 我认为是这样，但自上世纪 80 年代开始，我决定不再把时间浪费在将软件移植到 GNU 以外的系统上。我开始专注于推进 GNU 系统，使其不必使用任何非自由软件。至于将 GNU 程序移植到非类 GNU 系统就留给想在其他系统上运行它们的人们了。

Seth: POSIX 对于软件的自由很重要吗？

RMS: 本质上说，（遵不遵循 POSIX）其实没有任何区别。但是，POSIX 和 ISO C 的标准化确实使 GNU 系统更容易迁移，这有助于我们更快地实现从非自由软件中解放用户的目标。这个目标于上世纪 90 年代早期达成，当时Linux成为自由软件，同时也填补了 GNU 中内核的空白。

POSIX 采纳 GNU 的创新

我还问过 Stallman 博士，是否有任何 GNU 特定的创新或惯例后来被采纳为 POSIX 标准。他无法回想起具体的例子，但友好地代我向几位开发者发了邮件。

开发者 Giacomo Catenazzi，James Youngman，Eric Blake，Arnold Robbins 和 Joshua Judson Rosen 对以前的 POSIX 迭代以及仍在进行中的 POSIX 迭代做出了回应。POSIX 是一个 “ 活的 living ” 标准，因此会不断被行业专业人士更新和评审，许多从事 GNU 项目的开发人员提出了对 GNU 特性的包含。

为了回顾这些有趣的历史，接下来会罗列一些已经融入 POSIX 的流行的 GNU 特性。

Make

一些 GNU Make 的特性已经被 POSIX 的 make 定义所采用。相关的 规范 提供了从现有实现中借来的特性的详细归因。

Diff 和 patch

diff 和 patch 命令都直接从这些工具的 GNU 版本中引进了 -u 和 -U 选项。

C 库

POSIX 采用了 GNU C 库 glibc 的许多特性。 血统 Lineage 一时已难以追溯，但 James Youngman 如是写道：

“我非常确定 GCC 首创了许多 ISO C 的特性。例如，\_Noreturn 是 C11 中的新特性，但 GCC-1.35 便具有此功能（使用 volatile 作为声明函数的修饰符）。另外尽管我不确定，GCC-1.35 支持的可变长度数组似乎与现代 C 中的（ 柔性数组 conformant array ）非常相似。”

Giacomo Catenazzi 援引 Open Group 的 strftime 文章，并指出其归因：“这是基于某版本 GNU libc 的 strftime() 的特性。”

Eric Blake 指出，对于 getline() 和各种基于语言环境的 *_l() 函数，GNU 绝对是这方面的先驱。

Joshua Judson Rosen 补充道，他清楚地记得，在全然不同的操作系统的代码中奇怪地目睹了熟悉的 GNU 式的行为后，对 getline() 函数的采用给他留下了深刻的印象。

“等等……那不是 GNU 特有的吗？哦，显然已经不再是了。”

Rosen 向我指出了 getline 手册页 中写道：

getline() 和 getdelim() 最初都是 GNU 扩展。在 POSIX.1-2008 中被标准化。

Eric Blake 向我发送了一份其他扩展的列表，这些扩展可能会在下一个 POSIX 修订版中添加（代号为 Issue 8，大约在 2021 年前后）：

• ppoll
• pthread\_cond\_clockwait et al.
• posix\_spawn\_file\_actions\_addchdir
• getlocalename\_1
• reallocarray

关于用户空间的扩展

POSIX 不仅为开发人员定义了函数和特性，还为用户空间定义了标准行为。

ls

-A 选项会排除来自 ls 命令结果中的符号 .（代表当前位置）和 ..（代表上一级目录）。它被 POSIX 2008 采纳。

find

find 命令是一个 特别的 （ ad hoc ） for 循环 工具，也是 并行 parallel 处理的出入口。

一些从 GNU 引入到 POSIX 的 便捷操作 conveniences ，包括 -path 和 -perm 选项。

-path 选项帮你过滤与文件系统路径模式匹配的搜索结果，并且从 1996 年（根据 findutil 的 Git 仓库中最早的记录）GNU 版本的 find 便可使用此选项。James Youngman 指出 HP-UX 也很早就有这个选项，所以究竟是 GNU 还是 HP-UX 做出的这一创新（抑或两者兼而有之）无法考证。

-perm 选项帮你按文件权限过滤搜索结果。这在 1996 年 GNU 版本的 find 中便已存在，随后被纳入 POSIX 标准 “IEEE Std 1003.1,2004 Edition” 中。

xargs 命令是 findutils 软件包的一部分，1996 年的时候就有一个 -p 选项会将 xargs 置于交互模式（用户将被提示是否继续），随后被纳入 POSIX 标准 “IEEE Std 1003.1, 2004 Edition” 中。

Awk

GNU awk（即 /usr/bin 目录中的 gawk 命令，可能也是符号链接 awk 的目标地址）的维护者 Arnold Robbins 说道，gawk 和 mawk（另一个GPL 的 awk 实现）允许 RS（记录分隔符）是一个正则表达式，即这时 RS 的长度会大于 1。这一特性还不是 POSIX 的特性，但有 迹象表明它即将会是：

NUL 在扩展正则表达式中产生的未定义行为允许 GNU gawk 程序未来可以扩展以处理二进制数据。

使用多字符 RS 值的未指定行为是为了未来可能的扩展，它是基于用于记录分隔符（RS）的扩展正则表达式的。目前的历史实现为采用该字符串的第一个字符而忽略其他字符。

这是一个重大的增强，因为 RS 符号定义了记录之间的分隔符。可能是逗号、分号、短划线、或者是任何此类字符，但如果它是字符序列，则只会使用第一个字符，除非你使用的是 gawk 或 mawk。想象一下这种情况，使用省略号（连续的三个点）作为解析 IP 地址文档的分隔记录，只是想获取在每个 IP 地址的每个点处解析的结果。

mawk 首先支持这个功能，但是几年来没有维护者，留下来的火把由 gawk 接过。（mawk 已然获得了一个新的维护者，可以说是大家薪火传承地将这一特性推向共同的预期值。）

POSIX 规范

总的来说，Giacomo Catenzzi 指出，“……因为 GNU 的实用程序使用广泛，而且许多其他的选项和行为又对标规范。在 shell 的每次更改中，Bash 都会（作为一等公民）被用作比较。” 当某些东西被纳入 POSIX 规范时，无需提及 GNU 或任何其他影响，你可以简单地认为 POSIX 规范会受到许多方面的影响，GNU 只是其中之一。

共识是 POSIX 存在的意义所在。一群技术人员共同努力为了实现共同规范，再分享给数以百计各异的开发人员，经由他们的赋能，从而实现软件的独立性，以及开发人员和用户的自由。

via: https://opensource.com/article/19/7/what-posix-richard-stallman-explains

作者：Seth Kenlon 选题：lujun9972 译者：martin2011qi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

偶尔总会有人指出Linux中的POSIX违规（violation），通常的回答是“修复违规问题”，但有时李纳斯·托瓦兹认为POSIX特性是不完整的，至少他们维护Linux特性的情形下是这样的。因此，他们或许应该构建一层POSIX兼容层，即便这个分层会相对较慢和低效。

这一次，迈克尔·凯利斯克（Michael Kerrisk）报告了一个影响文件操作的POSIX违规。显然，在多线程操作期间读写文件会导致竞争出现，重写其它操作的改变。

关于这是否是POSIX的一个违规存在一些讨论，但到最后又有谁关心呢？数据重写（clobbering）是很糟糕的事情。在迈克尔提交部分代码去重现这个问题后，讨论的问题集中到该做什么去修复它。但迈克尔的观点是：“Linux从早期开始就与UNIX不一致。（如在1992年版的史蒂夫的APUE的191页讨论到fork()操作后在父进程与子进程之间文件偏移量的共享问题。尽管史蒂夫没有显式地讲清楚一致性的保证，但缺乏这个保证的推论这里的讨论可能有些没意义。）”

艾尔·维洛（Al Viro）和李纳斯一起设法解决这个修复。李纳斯尝试引入一个简单的互斥量去锁住文件，以便写操作无法互相重写。艾尔提出了自己的改进以改善李纳斯的补丁。

李纳斯一度解释过这个故障自身的历史。显然，从前这个用来告诉系统去哪里写文件的文件指针已经被锁在一个信号量中，所以只有一个进程可以在某一时刻对这个文件做任何操作。但是，他们从中拿走了这个信号量，以便在任何时候可以适应设备文件和其它非常规文件，因为当用户被禁止写入其中时它们就会陷入竞争状态。

这就是错误的由来。那个时候，它悄悄地通过了检查，未被发现。因为实际上对常规文件的读写仍然由内核自动处理。只有文件指针自身可以避免同步。而且，因为高速线程化的文件操作是一个非常罕见的需求，所以对任何人来说都需要很长时间才能遇到这个问题并报告它。

一个有趣的小细节是当李纳斯和艾尔在寻找一个修复方案时，艾尔一度抱怨李纳斯采用的方法并不能支持一些确定的架构，包括ARM和PowerPC。李纳斯的回应是“我怀疑关心这个是否有意义。[...]如果使用ARM/PPC架构的人停止抱怨，他们可以往gcc中加入struct-return的支持。”

看到这些问题突然产生并得到处理通常是很有趣的。在某些情况下，这个修复的部分工作必须在内核中进行，部分在GCC中，部分在其它地方。在这个特例里，艾尔认为整个事情都应该在内核里处理，他在灵感的激发下往补丁中写入了自己的版本，李纳斯也接受了。

安迪·克伦（Andi Kleen）则想为perf增加底层CPU事件支持。问题在于这可能会导致大量的底层事件，而且会因CPU的变化而改变。即使为了所有类型的CPU把可能的时间都存储在内存里，也可能会显著地增加内核的运行大小。因此，把这个信息硬编码进内核的方法是有问题的。

他也指出OProfile工具依赖于这些时间的公开可用列表，尽管他表示OProfile开发者并非总维持他们的列表与最新的可用版本一致。

为了解决这些问题，安迪提交了一个补丁，允许perf识别在给定的系统上为特定的CPU需要那种事件列表，并自动从起始位置下载这个列表的最新版本。然后perf可以解释这个列表并分析其中的事件，不会使内核负载过重。

有各种各样对安迪代码的反馈，其中大部分涉及到应该在哪个目录下保存事件列表和文件如何命名。这份代码本身的特性似乎得到了很好的回应。一处细节证明了安迪的代码比其他人的更有争议，就是将列表下载到用户家目录下的一个子目录。安迪表示如果不这样做的话，用户可能会以系统管理员的身份去下载事件列表，这会是危害安全的操作。

萨沙·莱文（Sasha Levin）最近发布了一个脚本来从堆栈转储中把十六进制的偏移量翻译成有意义的指向内核源码文件的行号。因此诸如“ffffffff811f0ec8”形式的十六进制表示可以被翻译成“fs/proc/generic.c:445”。

然而，结果表明李纳斯·托瓦兹正打算从堆栈转储中移除十六进制偏移量，具体原因是他们难以理解。所以萨沙的代码看起来过时了。[译者注：程序媛，伤不起！:< ]

他们在这个问题上纠结了一番。起初，萨沙打算依赖存储在System.map文件里的数据区补偿，但李纳斯指出包括他在内的有些人并不会保留System.map文件。李纳斯推荐使用/usr/bin/nm从编译好的内核文件中提取符号表。

所以，似乎萨沙的脚本可能确实为调试堆栈转储提供了有意义的文件和行号，假设堆栈转储提供足够的信息去完成计算。

via: http://www.linuxjournal.com/content/diff-u-whats-new-kernel-development-0

原文作者：Zack Brown

译者：KayGuoWhu 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

Linux 和 Unix 属于多任务的操作系统，也就是说一个系统在同一时间段内能运行多重任务(进程)。在这个新的博客系列，我将会列出相关的 Linux 和 Unix 作业（job）控制的命令，你可以通过这些命令在 Bash 或 Korn 还有 POSIX shell 下实现执行多重任务。

什么是作业控制？

作业控制不只是能够停止/挂起(stop/suspend)正在执行的进程(命令)，也可以继续/唤醒(continue/resume)执行你需要的每一个进程。这完全可以用你的操作系统和 bash/ksh 之类的 shell 或 POSIX shell 完成。

谁给作业控制的提供了环境？

Bash / Korn shell，或者是 POSIX shell 提供给了作业控制的环境。

跟作业表打个招呼吧

你的 shell 会留有一张当前作业的表单，称为作业表。当你键入命令时，shell 会给它分配一个 jobID(也称作 JOBSPEC)。一个 jobID 或 JOBSPEC只是很小的整数数值。

1: 创建你的首个 Linux/Unix 作业

我要运行一个名为 xeyes 的命令，它会在屏幕上显示两个椭圆的眼睛,输入： $ xeyes &

输出样例：

Fig.01: 在后台运行 xeyes 命令

我使用&符号让一个 job 在后台运行。shell 会打印一行信息类似如下:

[1] 6891

在这个例子中，有两个数字输出，分别表示：

• 1 : 在后台执行的 xeyes 任务的作业号为 1。
• 6891 : 作业1的进程ID。

我在多执行一些 job:

## 启动一个文本编辑器，X 的系统负载显示，和 sleep 命令 ##
gedit /tmp/hello.c &
xload &
sleep 100000 &

2: 列出当前的作业

要查看当前 shell 的激活的任务状态，输入：

$ jobs
$ jobs -l

输出如下:

[1]   9379 Running                 xeyes &
[2]   9380 Running                 gedit /tmp/hello.c &
[3]-  9420 Running                 xload &
[4]+  9421 Running                 sleep 100000 &

简要描述如下：

你也可以用 ps 命名列出当前系统正在运行的进程:

$ ps

3: 停止或挂起正在运行的作业

按下[Ctrl]-[Z]键或使用kill 命令,如下所示：

kill -s stop PID

举个例子，启动ping 命令，然后用 Ctrl-Z 键来停止 ping 命令作业：

Animated gif 01: 挂起 ping 命令作业

4: 在前台恢复 挂起的/停止的作业

让我们恢复处于停止状态下的作业，让它回到前台继续运行，要将其变成当前作业，必须借助fg 命令。具体语法如下：

## ping 命令的作业号的值为5 ##
fg %5

我也可以规定命令行开端符合字符串"ping"的作业[译注：不能出现不明确的字符串，例如如果后台有两个 vim 进程而你敲入 fg %vim 会报错。]:

## %String ##
fg %ping

输出样例：

64 bytes from www.cyberciti.biz (75.126.153.206): icmp_req=3 ttl=53 time=265 ms
64 bytes from www.cyberciti.biz (75.126.153.206): icmp_req=4 ttl=53 time=249 ms
64 bytes from www.cyberciti.biz (75.126.153.206): icmp_req=5 ttl=53 time=267 ms
^C

5: 在后台恢复 挂起/停止状态的作业

在这个例子中，我使用yum 命令更新所有安装在 Redhat 或 CentOS Linux 生产服务器上的软件包并置于后台作业。

# yum -y update &>/root/patch.log &

然而，由于一些原因(例如,过载问题)我决定停止这个作业20分钟：

# kill -s stop %yum

输出样例：

[7]+  Stopped                 yum -y update &>/root/patch.log &

用 bg 重启停止在后台的 yum 进程

现在，我将要恢复停止的 yum -y update &>/root/patch.log & 作业，键入：

# bg %7

或者：

# bg %yum

输出样例：

[7]+ yum -y update &>/root/patch.log &

6: 杀死作业/进程

杀死yum 命令进程，输入如下kill 命令及其作业号 7：

# kill %7

或者

# kill 进程ID

输出样例：

[7]+  Terminated              yum -y update &>/root/patch.log &

在 Linux/FreeBSD/OS X Unix 下你也可以使用 killall 命令通过名字杀死进程或是 jobID 而不是通过 PID

7 为什么当我登出后 shell 会清除我的所有后台作业

在这个例子中,我将会启动 pdfwriter.py 来批量生成这个站点的 pdf 文件:

~/scripts/www/pdfwriter.py --profile=faq --type=clean --header=logo\
--footer-left "nixCraft is GIT UL++++ W+++ C++++ M+ e+++ d-" \
--footer-right "Page [of] of [total]" &

一旦当我登出shell时，pdfwriter.py 作业就会被我的 shell 杀死。为了克服这个问题需要使用shell的内置命令 disown 来告诉 shell 不要发送 HUP 信号,键入：

$ ~/scripts/www/pdfwriter.py --profile=faq .... &
$ disown
$ exit

8 使用一个名为 nohup 的外部命令阻止在登出时杀死作业

你也可以使用nohup 命令在你退出 shell 后执行作业:

$ nohup ~/scripts/www/pdfwriter.py --profile=faq .... &
$ exit

9: 查找最后的作业的 PID

为了查找最近在后台执行的(异步)命令的进程ID，可使用 bash shell 的特殊参数 $!

$ gedit foo.txt &
$ echo "最近在后台执行的job 的PID - $!" 

输出样例：

最近在后台执行的job 的PID - 9421

10: 等候作业完成

wait 命令会等候给予的进程ID 或 作业ID指定的进程，然后报告它的终止状态。语法如下：

/path/to/large-job/command/foo &
wait $!
/path/to/next/job/that-is-dependents/on-foo-command/bar

这是我的一个工作脚本：

#!/bin/bash
# A shell script wrapper to create pdf files for our blog/faq section
########################################################################
# init() - Must be run first 
# Purpose - Create index file in $_tmp for all our wordpress databases 
########################################################################
init(){
 _php="/usr/bin/php"
 _phpargs="-d apc.enabled=0"
 _base="~/scripts"
 _tmp="$_base/tmp"
 _what="$1"
 for i in $_what
 do
        [[ ! -d "$_tmp/$i" ]] && /bin/mkdir "$_tmp/$i"
        $_php $_phpargs -f "$_base/php/rawsqlmaster${i}.php" >  "$_tmp/$i/output.txt"
 done
}

#####################################################
# Without index file, we can out generate pdf files
#####################################################
init blog

###########################################################
# Do not run the rest of the script until init() finished
###########################################################
wait $!

## Alright, create pdf files 
~/scripts/www/pdfwriter.py --profile=blog --type=clean --header=logo\
--footer-left "nixCraft is GIT UL++++ W+++ C++++ M+ e+++ d-" \
--footer-right "Page [of] of [total]"

Linux 和 Unix 作业控制命令总结列表

关于 shell 内置命令和外部命令的小注

运行下面的 type 命令找出给予命令是否属于内部或外部的。

type -a fg bg jobs disown

输出样式：

fg is a shell builtin
fg is /usr/bin/fg
bg is a shell builtin
bg is /usr/bin/bg
jobs is a shell builtin
jobs is /usr/bin/jobs
disown is a shell builtin

在几乎所有情况下，你都需要使用 shell 的内置命令。所有外部命令例如 /usr/bin/fg 或 /usr/bin/jobs 工作在一个不同的 shell 环境下，而不能用在父 shell 的环境下。

总结

我希望你能喜欢这篇博文系列(rss 订阅),我建议你阅读下面的更多信息：

• 在我们的 faq 章节查阅有关进程管理的文章disoen 命令示例，jobs 命令示例，bg 命令示例，和fg 命令示例。
• Man pages bash(1), ksh(1), ps(1), kill(1)
• Korn shell (ksh93) 文档.
• NU bash shell 文档.

我会计划在这个系列添加更多深入的教程。若果你需要看到具体的主题，请在下方评论让我知道。

via: http://www.cyberciti.biz/howto/unix-linux-job-control-command-examples-for-bash-ksh-shell/

译者：Luoxcat 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出