POSIX 是什麼？讓我們聽聽 Richard Stallman 的詮釋

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 中國: https://github.com/Linux-CN/archive