POSIXとは正確には何ですか？

私は、ウィキペディアのページ次の抜粋に気づいまで..私はPOSIXはしばしば、どこでも言及見て、私はそれは、ベースラインのUNIX標準であると想定していた：ザ・オープン・グループ

Open Groupは、UNIX商標の認定機関として最も有名であり、POSIX標準を拡張し、UNIXシステムの公式定義である Single UNIX Specification技術標準の公開です。

UNIXシステムの公式の定義がPOSIXの拡張である場合、POSIXとは正確には何ですか？、、、それは確かにUNIXの世界の試金石のようですが、全体像にどのように適合するのか分かりません。

POSIXは、Single UNIX Specificationよりもずっと前の1988年の最初の標準でした。これは、すべてのさまざまなUNIXフォークとUNIXライクシステムを統合する試みの1つでした。POSIXはIEEE規格ですが、IEEEはUNIX®商標を所有していないため、当時の既存のUNIX APIに基づいていますが、規格はUNIX®ではありません。最初の標準POSIX.1は、正式のIEEE STD 1003.1-1988として知られている。[ 1 ] IEEE規格のコピーを得るために実質的な料金を請求しました。

Open Groupは、IEEEのPOSIX標準の作業に基づいて、1997年にSingle UNIX Specification（SUSv2）をリリースしました。SUSv3は、2001年にIEEEとオースティングループとして知られるオープングループの共同ワーキンググループからリリースされました。SUSv3はPOSIX：2001 [ 2 ] としても知られています。POSIX：2004とSUSv4の中核であるPOSIX：2008もあります。UNIX®については、現在の登録商標所有者が言うように、UNIX®は何でもあります。1994年以来、それはオープングループです。

ノベルは、UNIX®が生まれたAT＆T / USLからUNIX®システム事業を買収しました。1994年、彼らはUNIX®商標の権利をX / Open [ 3 ] に売却し、現在はOpen Groupとして知られています。そして、彼らはUNIXWARE®ようSCOにUNIX®のソースコードを販売した。[ 3 ]UNIX®自体が二股た何度[ 4 ] [ 5 ] AT＆Tのライセンスモデルに部分的に起因します。UNIX®を購入すると、オペレーティングシステムの完全なソースと、それを構築するための完全なツールチェーンが得られました。ソースの変更は、AT＆TからUNIX®のライセンスを所有している人が配布および使用できます。ライセンス料は数千単位でした。

BSDは、Berkeleyのプロジェクトであり、UNIX®オペレーティングシステムに多くの拡張機能を追加しました。BSDコードは、AT＆Tのソースよりもはるかに自由なライセンスの下でリリースされ、GNUプロジェクトやLinuxが使用するGPLとは異なり、ライセンス料やソースと共に配布する必要さえありませんでした。これにより、BSDコードの大部分がさまざまな商用UNIXフォークに含まれるようになりました。4.3BSD頃までに、元のAT＆TUNIX®ソースコードの必要性はほぼ置き換えられました。FreeBSD / NetBSD / OpenBSDはすべて4.3BSDのフォークであり、完全なオペレーティングシステムであり、元のAT＆Tソースコードはありません。UNIX®商標の権利もありませんが、それらのコードの多くは商用UNIXオペレーティングシステムで使用されています。

Linuxは1991年に開発されましたが、BSDとは異なりゼロから開発され、UNIXユーザー空間の多くのクリーンルーム実装である既存のGNUプロジェクトを使用しています。互換性のためにPOSIXの多くを実装し、設計上はUNIXに似ていますが、BSDが持っているAT＆TまたはUNIX®との密接な関係はありません。

POSIX 7が定義する最も重要なこと

1. C API

   次のようなものでANSI Cを大幅に拡張します。

   • より多くのファイル操作：mkdir、dirname、symlink、readlink、link（ハードリンク）、 、poll()、、statsyncnftw()
   • プロセスおよびスレッド：fork、execl、wait、pipe、semaphors sem_*、共有メモリ（shm_*）kill、スケジューリングパラメータ（nice、sched_*）、 、、sleepmkfifosetpgid()
   • ネットワーキング： socket()
   • メモリ管理：mmap、mlock、mprotect、madvise、brk()
   • ユーティリティ：正規表現（reg*）

   これらのAPIは、依存する基礎となるシステム概念も決定forkします。たとえば、プロセスの概念が必要です。

   多くのLinuxシステムコールは、例えば、特定のPOSIX C API関数を実装し、Linux対応をするために存在しsys_write、sys_read...これらのシステムコールの多くは、しかし、Linux固有の拡張機能を持っています。

   主要なLinuxデスクトップ実装：glibc。多くの場合、システムコールの浅いラッパーを提供します。

2. CLIユーティリティ

   例えば：cd、ls、echo、...

   多くのユーティリティは、対応するC API関数の直接シェルフロントエンドですmkdir。

   主要なLinuxデスクトップの実装：小さなもののためにGNUのCoreutils、大きなもののために別々のGNUプロジェクト：sed、grep、awk、...いくつかのCLIユーティリティはバッシュで実装されている組み込み関数として。

3. シェル言語

   例えば、 a=b; echo "$a"

   主要なLinuxデスクトップ実装：GNU Bash。

4. 環境変数

   例：HOME、PATH。

   PATH スラッシュがPATH検索を妨げる方法を含む検索意味論が指定されます。

5. プログラム終了ステータス

   ANSI Cは言います0かEXIT_SUCCESS、成功のために、EXIT_FAILURE失敗のために、と定義され、残りの実装を残します。

   POSIXの追加：

   • 126：コマンドは見つかりましたが、実行できません。

   • 127： コマンドが見つかりません。

   • > 128：シグナルで終了しました。

     しかし、POSIXは128 + SIGNAL_IDBashで使用されるルールを指定していないようです：プロセスが終了したときのデフォルトの終了コード？

6. 正規表現

   BRE（基本）とERE（拡張）の2つのタイプがあります。Basicは非推奨であり、APIを壊さないように維持されています。

   これらはC API関数によって実装され、CLIユーティリティ全体で使用されます。たとえばgrep、デフォルトでBREを受け入れ、EREでEREを受け入れます-E。

   例えば： echo 'a.1' | grep -E 'a.[[:digit:]]'

   主要なLinux実装：glibcは、regex.hの下の関数を実装しますgrep。このようなプログラムはバックエンドとして使用できます。

7. ディレクトリ構造

   例：/dev/null、/tmp

   Linux FHSはPOSIXを大幅に拡張します。

8. ファイル名

   • / はパスセパレーターです
   • NUL 使用できません
   • .はcwd、..親
   • ポータブルなファイル名
     • 最大14文字、フルパスには256文字を使用します
     • 次のもののみを含めることができます。 a-zA-Z0-9._-

   参照：https : //stackoverflow.com/questions/18550253/what-is-posix-compliance-for-filesystem

9. コマンドラインユーティリティAPIの規則

   必須ではありません。POSIXで使用されますが、他のどこにも、特にGNUでは使用されません。しかし、実際には、制限が強すぎます。たとえば、1文字のフラグのみ（例-a）、ダブルハイフンの長いバージョン（例--all）はありません。

   広く使用されているいくつかの規則：

   • - ファイルが期待される標準入力を意味します
   • --フラグを終了します。たとえばls -- -l、という名前のディレクトリをリストします-l

   参照：https : //stackoverflow.com/questions/8957222/are-there-standards-for-linux-command-line-switches-and-arguments

10. 「POSIX ACL」（アクセス制御リスト）。たとえば、のバックエンドとして使用されますsetfacl。

    これは廃止されましたが、Linuxをsetxattr含むいくつかのOSに実装されました。

誰がPOSIXに準拠していますか？

多くのシステムはPOSIXに厳密に準拠していますが、実際には標準を維持しているOpen Groupによって認定されているシステムはほとんどありません。注目すべき認定されたものは次のとおりです。

• OS X（Apple）Xは10とUNIXの両方を表します。2001年頃にリリースされた最初のApple POSIXシステムでした。https：//stackoverflow.com/questions/5785516/is-osx-a-posix-osも参照してください。
• AIX（IBM）
• HP-UX（HP）
• Solaris（Oracle）

ほとんどのLinuxディストリビューションは非常に準拠していますが、準拠チェックの支払いを望まないため、認定されていません。InspurのK-UXとHuaweiのEulerOSは、2つの認定された例です。

認定システムの公式リストは、https：//www.opengroup.org/openbrand/register/およびwikiページにあります。

窓

Windowsは、その専門のディストリビューションのいくつかにPOSIXを実装しました。

これはオプション機能であるため、プログラマーはほとんどのエンドユーザーアプリケーションでこの機能に依存できませんでした。

サポートはWindows 8で廃止されました。

• https://stackoverflow.com/questions/4746043/where-does-microsoft-windows-7-posix-implementation-currently-stand
• https://superuser.com/questions/495360/does-windows-8-still-implement-posix
• 機能リクエスト：https : //windows.uservoice.com/forums/265757-windows-feature-suggestions/suggestions/6573649-full-posix-support

2016年、「Linux用Windowsサブシステム」と呼ばれる新しい公式のLinuxライクなAPIが発表されました。これは、Linuxのシステムコール、ELF実行中の部品が含ま/procファイルシステム、バッシュ、GCC、（？TODO可能性が高いのglibc）、apt-getおよびより：https://channel9.msdn.com/Events/Build/2016/P488をので、私はそれと信じていますWindowsでは、すべてではないにしてもPOSIXの多くを実行できます。ただし、エンドユーザーではなく開発者/展開に焦点を当てています。特に、Windows GUIへのアクセスを許可する計画はありませんでした。

公式のMicrosoft POSIX互換性の歴史的概要：http : //brianreiter.org/2010/08/24/the-sad-history-of-the-microsoft-posix-subsystem/

Cygwinは、Windows用の「実質的なPOSIX API機能を提供する」ことで有名なGPLサードパーティプロジェクトですが、「Windowsで実行する場合はソースからアプリケーションを再構築する」必要があります。MSYS2は、Cygwinの上にさらに機能を追加するように思われる関連プロジェクトです。

アンドロイド

Androidには、Android Oの時点でPOSIXを完全にサポートしていない独自のCライブラリ（Bionic）があります：https : //stackoverflow.com/questions/27604455/is-android-posix-compatible

ボーナスレベル

Linuxの標準ベースはさらにPOSIXを拡張します。

非フレームインデックスを使用すると、読みやすく検索しやすくなります。http：//pubs.opengroup.org/onlinepubs/9699919799/nfindex.html

grepping用の完全なzip形式のHTMLページを取得します：https ://stackoverflow.com/questions/453993/is-there-a-listing-of-the-posix-api-functions/45832939#45832939

POSIXは、ポータブルオペレーティングシステムの標準です。準拠オペレーティングシステムがソフトウェア（ソケット、ファイルI / O、スレッドなど）に提供する必要がある特定のユーティリティ、API、およびサービスと、プログラムからこれらを呼び出す方法に関する規則について説明します。

ある考えは、あるPOSIX準拠のOS用に作成されたプログラムは、非POSIX準拠のOS間で移植するよりも、別のPOSIX準拠のOSに移植する方が簡単だということです。これが、FreeBSDからWindowsにアプリケーションを移植するよりも、FreeBSDからLinuxにアプリケーションを移植する方がはるかに簡単な理由です（Windowsは表面上POSIXのサブセットをサポートしています）。

POSIXはUNIXのサブセットであり、他のオペレーティングシステム用のさまざまなUnixライクな環境をカバーすることを目的としています。これにはもともと、VMS用のEunice、Windows NTのPOSIXパーソナリティ、Apollo Domain / OSなどの環境が含まれていました。これは、動作がUnixと非Unixで共通しているオペレーティングシステムサービスのサブセット用の標準の移植性APIと考えることができます。詳細については、http：//standards.ieee.org/develop/wg/POSIX.htmlを参照してください。