私はPOSIXを頻繁に言及しているのを目にし、Wikipediaのページで次の抜粋に気づくまで、それをベースラインUNIX標準であると想定していました。 The Open Group
Open GroupはUNIX商標の認証機関として最も有名であり、Single UNIX Specification技術標準、これはPOSIX標準を拡張し、UNIXシステムの公式定義です。
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年にシングルUNIX仕様(SUSv2)をリリースしました。 SUSv3は、2001年に、IEEEとオースティングループとして知られるオープングループの共同作業グループからリリースされました。 SUSv3はPOSIX:2001 [ 2 ]とも呼ばれます。現在、POSv:2004とSUSv4の中核であるPOSIX:2008もあります。 UNIX®が何であるかについては、UNIX®は現在の登録済み商標所有者がそうであると言っているものです。 1994年以来、それはオープングループです。
ノベルは、UNIX®の誕生地であるAT&T/USLからUNIX®システム事業を買収しました。 1994年、彼らはUNIX®商標の権利をX/Open []に売却し、現在はThe Open Groupとして知られています。その後、UNIX®のソースコードをSCOに売却しました。[]UNIX®自体が何度も分岐しました[ 4 ] [ 5 ] AT&Tのライセンスモデルに一部起因します。UNIX®を購入すると、オペレーティングシステムの完全なソースとそれを構築するための完全なツールチェーンが提供されます。ソースへの変更は誰でも配布して使用できますAT&TからUNIX®へのライセンスを所有している人。ライセンス料は数千ドルでした。
BSDはバークレーのプロジェクトで、UNIX®オペレーティングシステムにいくつかの機能強化を追加しました。 BSDコードは、AT&Tのソースよりもはるかに自由なライセンスの下でリリースされ、GNU ProjectおよびLinuxが使用するGPLとは異なり、ライセンス料やソースとともに配布する必要さえありませんでした。これにより、BSDコードの大部分がさまざまな商用UNIXフォークに含まれるようになりました。4.3BSD頃までに、元のAT&TUNIX®ソースコードの必要性はほとんどなくなりました。FreeBSD/ NetBSD/OpenBSDは、すべて4.3BSDのフォークです。それらは完全なオペレーティングシステムであり、元のAT&Tソースコードはありません。UNIX®商標に対する権利もありませんが、コードの多くは商用UNIXオペレーティングシステムで使用されています。UNIXで使用されるソケットAPIはBSDで開発されましたまた、Unix Fast Filesystemコードは、独自の拡張機能を備えたSolarisなどのさまざまなUNIXオペレーティングシステムで借用および使用されました。
Linuxは1991年に開発されましたが、BSDとは異なり、ゼロから開発され、既存のGNU Projectを使用しています。これは、UNIXユーザー空間の多くのクリーンルーム実装です。多くのPOSIXを実装しています。互換性があり、設計はUNIXに似ていますが、BSDが持っているAT&TまたはUNIX®との密接な関係はありません。
最も重要なこと POSIX 7 定義
非常に ANSI Cを拡張 のようなもので:
mkdir
、dirname
、symlink
、readlink
、link
(ハードリンク)、 poll()
、stat
、sync
、 nftw()
fork
、execl
、 wait
、pipe
、セマフォ _sem_*
_ 、共有メモリ(_shm_*
_)、kill
、スケジューリングパラメータ(Nice
、_sched_*
_)、sleep
、mkfifo
、 setpgid()
socket()
mmap
、mlock
、mprotect
、madvise
、 brk()
reg*
_)これらのAPIは、APIが依存する基本的なシステム概念も決定します。 fork
にはプロセスの概念が必要です。
多くの Linuxシステムコール は、特定のPOSIX C API関数を実装してLinuxに準拠させるために存在します。 _sys_write
_、_sys_read
_、...ただし、これらのシステムコールの多くにはLinux固有の拡張機能もあります。
主要なLinuxデスクトップの実装:glibc。多くの場合、システムコールに浅いラッパーを提供します。
例:cd
、ls
、echo
、...
多くのユーティリティは、対応するC API関数の直接のシェルフロントエンドです。 mkdir
。
主要なLinuxデスクトップの実装:GNU小さなものにはCoreutils、大きなものには別個のGNU大きなものにはプロジェクト:sed
、grep
、awk
、...一部のCLIユーティリティはBashによって実装されています 組み込みとして 。
例:_a=b; echo "$a"
_
主要なLinuxデスクトップの実装: GNU Bash 。
例:HOME
、PATH
。
PATH
検索のセマンティクスが指定されています 、 スラッシュがPATH
searchを防ぐ方法 を含めます。
ANSI Cは、成功の場合は_0
_または_EXIT_SUCCESS
_、失敗の場合は_EXIT_FAILURE
_と言い、残りの実装は定義されたままにします。
POSIXは以下を追加します:
_126
_:コマンドは見つかりましたが実行可能ではありません。
_127
_:コマンドが見つかりません。
_> 128
_:シグナルによって終了しました。
しかし、POSIXはBashが使用する_128 + SIGNAL_ID
_ルールを指定していないようです: プロセス終了時のデフォルトの終了コード?
BRE(基本)とERE(拡張)の2つのタイプがあります。 Basicは非推奨であり、APIを壊さないようにするためだけに残されています。
これらはC API関数によって実装され、CLIユーティリティ全体で使用されます。 grep
はデフォルトでBREを受け入れ、_-E
_のEREを受け入れます。
例:_echo 'a.1' | grep -E 'a.[[:digit:]]'
_
主要なLinux実装:glibcは regex.h で関数を実装し、grep
のようなプログラムがバックエンドとして使用できます。
例:_/dev/null
_、_/tmp
_
Linux [〜#〜] fhs [〜#〜] はPOSIXを大幅に拡張します。
/
_はパス区切り文字ですNUL
は使用できません.
_はcwd
、_..
_は親a-zA-Z0-9._-
_参照: https://stackoverflow.com/questions/18550253/what-is-posix-compliance-for-filesystem
必須ではありません。POSIXで使用されていますが、他にはほとんどありません。特にGNUでは使用されていません。しかし、本当です、それはあまりにも制限的です。単一文字のフラグのみ(例:_-a
_)、二重ハイフンの長いバージョンはありません(例:_--all
_)。
広く使用されているいくつかの規則:
-
_は、ファイルが予期されるstdinを意味します--
_はフラグを終了します。 _ls -- -l
_という名前のディレクトリを一覧表示する_-l
_「POSIX ACL」(アクセス制御リスト)、たとえば setfacl
のバックエンドとして使用されます。
これは 廃止されました ですが、 Linuxでsetxattr
を含むいくつかのOSで実装されました。
誰がPOSIXに準拠していますか?
多くのシステムはPOSIXに厳密に従っていますが、実際には、標準を維持するOpen Groupによって認定されているシステムはほとんどありません。注目の認定されたものは次のとおりです。
ほとんどのLinuxディストリビューションは非常に準拠していますが、準拠性の確認を望まないため、認定されていません。 InspurのK-UX および HuaweiのEulerOS は、2つの認定された例です。
認定システムの公式リストは https://www.opengroup.org/openbrand/register/ および wiki page にもあります。
Windows
Windowsは、一部のプロフェッショナルディストリビューションにPOSIXを実装しました。
これはオプション機能であるため、プログラマはほとんどのエンドユーザーアプリケーションでこの機能に依存できませんでした。
サポートはWindows 8で廃止されました:
2016年に、「Linux用のWindowsサブシステム」と呼ばれる新しいLinuxのような公式APIが発表されました。 Linuxシステムコール、ELF実行、_/proc
_ファイルシステムの一部、Bash、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には、独自のCライブラリ(Bionic)があり、Android O: https://stackoverflow.com/questions/27604455/is-Android-posix -互換
ボーナスレベル
Linux Standard Base はPOSIXをさらに拡張します。
非フレームインデックスを使用してください。それらはより読みやすく、検索可能です。 http://pubs.opengroup.org/onlinepubs/9699919799/nfindex.html
Grepping用の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からLinuxに移植する方が、FreeBSDからWindowsに移植するよりもはるかに簡単な理由です(Windowsは表面上はPOSIXのサブセットをサポートしています)。
POSIXはUNIXのサブセットであり、他のオペレーティングシステム用のさまざまなUnixライクな環境をカバーすることを目的としています。これには元々、Eunice for VMS、Windows NTのPOSIXパーソナリティ、Apollo Domain/OSなどの環境が含まれていました。これは、UNIXと非Unix間で動作が共通するオペレーティングシステムサービスのサブセット用の標準の移植性APIと考えることができます。詳細は http://standards.ieee.org/develop/wg/POSIX.html を参照してください。