UNIX哲学のソースを表示

{{翻訳中途|1=[[:en:Unix_philosophy]]　（本文に英文が移されています）|date=2020年6月4日}}
'''UNIX哲学'''（ユニックスてつがく、{{lang-en-short|The UNIX Philosophy}}）とは、[[ソフトウェア]]開発の文化的な規範と哲学のまとまりであり、[[UNIX]] [[オペレーティングシステム|OS]]開発者たちの[[経験]]に基づくものとされている。その内容は発言者によって異なり、以下の点に留意が必要である：
* UNIXが開発された1971年から10年以上後の発言が大半である
*発言者にはUNIX開発と関わり合いが希薄な人物も含まれている
*UNIXを生み出した[[ケン・トンプソン]]や[[デニス・リッチー]]は"哲学"(philosophy)という表現をしていない
*哲学に反して商用UNIXには大規模で多機能な[[ソフトウェア]]が含まれている場合がある

すなわち、この哲学は当初から一貫して存在していたわけではなく、UNIXに関わる全ての人の共通認識でもなく、UNIXの現在や過去の状況を必ずしも的確に表現しているわけでもない。妥当性や有効性が普遍的に立証されているわけでもない。UNIXに関心を示す人々の一部の希望、願望、理想にすぎない。

== 起源 ==
1978年のBell System Technical Journal<ref>{{cite journal|url=https://archive.org/details/bstj57-6-1899/mode/2up|title=Unix Time-Sharing System: Foreword|author=[[Doug McIlroy]], E. N. Pinson, B. A. Tague|publisher=Bell Laboratories|journal=The Bell System Technical Journal|date=8 July 1978|pages=1902–1903}}</ref>に[[ダグラス・マキルロイ]]<ref name=taoup-ch1s6>{{cite book |first=Eric S. |last=Raymond |title=The Art of Unix Programming |year=2004 |section=Basics of the Unix Philosophy |section-url=http://www.catb.org/~esr/writings/taoup/html/ch01s06.html |url=http://www.catb.org/~esr/writings/taoup/html/ |publication-date=2003-09-23 |publisher=Addison-Wesley Professional |isbn=0-13-142901-9 |author-link=Eric_S._Raymond |access-date=2016-11-01}}</ref>他によって記載されている：

# それぞれのプログラムが1つのことをうまくこなすように。新しい仕事をするために、新しい「機能」を追加して古いプログラムを複雑にするのではなく、新しいプログラムを構築する。
# すべてのプログラムの出力が、まだ見ぬ別のプログラムの入力になること。出力に余計な情報を入れないように。厳密に列挙された入力形式やバイナリ形式は避ける。インタラクティブな入力にこだわらない
# ソフトウェアはもちろんOSであっても、早期に、理想としては数週間以内に試せるよう設計・構築する。不器用な部分は躊躇なく捨てて作り直すように
# 回り道をしても、使い終わった後に捨てることになっても、プログラミングの作業を軽減するためには、お手伝いさんではなくツールを使う

その後、[[:en:Peter H. Salus]]が『A Quarter-Century of Unix』（1994年）<ref name=taoup-ch1s6 />にまとめている：
* 一つのことをうまくやるプログラムを書く
* 連携するプログラムを書く
* 普遍的なインターフェースであるテキストストリームを扱うプログラムを書く

1974年のUnix論文<ref>{{citation | author1=[[Dennis Ritchie]] | author2=[[Ken Thompson]] | title=The UNIX time-sharing system | journal=[[Communications of the ACM]] | volume=17 | issue=7 | year=1974 | pages=365–375 | url=https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf | doi=10.1145/361011.361061| s2cid=53235982 }}</ref>で、[[ケン・トンプソン]]と[[デニス・リッチー]]はUNIXの設計で以下を考慮したと述べている：
* プログラムを書いたり、テストしたり、実行したりするのが簡単に行えるようシステムを設計した
* 当初のバージョンでは1人のユーザーしかサポートしていなかったものの、システムを対話的に使用できるようにした
* 適切に設計された対話型システムは、「[[バッチ処理]]」システムよりもはるかに生産的で満足のいくものであると信じている
* サイズの制約は経済性だけでなく、かえって設計をエレガントにする方向に働いた
* すべてのUnixソフトウェアはUnixの下で保守されている

==マキルロイ: UNIXの四半世紀==
[[パイプ (コンピュータ)|パイプ]]の発明者でありUNIX創始者の一人でもある[[ダグラス・マキルロイ|マキルロイ]]はこの哲学を以下のように要約した：

{{Quotation|これがUNIXの哲学である。<br />一つのことを行い、またそれをうまくやる[[プログラム (コンピュータ)|プログラム]]を書け。<br />協調して動くプログラムを書け。<br />[[標準ストリーム|標準入出力]]（[[ストリーム (プログラミング)|テキスト・ストリーム]]）を扱うプログラムを書け。標準入出力は普遍的インターフェースなのだ。|ダグラス・マキルロイ|UNIXの四半世紀}}

この哲学は「一つのことを、うまくやれ」とさらに要約されることがある。このうち3つめだけがUNIXに特有である。

==パイク: Cプログラミングに関する覚え書き==
（注意: これは直接にはUNIX哲学ではない。強い結びつきのあるC言語の記述ではある）

[[ロブ・パイク]]は ''Notes on Programming in C'' <ref>{{Cite web|url=http://www.lysator.liu.se/c/pikestyle.html|first=Rob|last=Pike|title=Notes on Programming in C|date=1989-02-21 |accessdate=2008年11月21日 }}</ref>で以下をプログラミングの格言として提案している。UNIX哲学と共通点がある。

* ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。
<!--
Rule 1.  You can't tell where a program is going to spend its time.  Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.
-->

* ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。
<!--
Rule 2.  Measure.  Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.
-->

* ルール3: 凝った(Fancy)[[アルゴリズム]]は<math>n</math>が小さいときには遅く、<math>n</math>はしばしば小さい。凝ったアルゴリズムは大きな定数を持っている<ref group="注釈">凝ったアルゴリズムは、それ自身がすでに大きなコストであるということ。</ref>。<math>n</math>が頻繁に大きくなることがわかっていないなら、凝ってはいけない（<math>n</math>が大きくなるときでさえ、ルール2が最初に適用される）。
<!--
Rule 3.  Fancy algorithms are slow when n is small, and n is usually small.  Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy.  (Even if n does get big, use Rule 2 first.)   For example, binary trees are always faster than splay trees for workaday problems.
-->

* ルール4: 凝ったアルゴリズムはシンプルなそれよりバグを含みやすく、実装するのも難しい。シンプルなアルゴリズムとシンプルな[[データ構造]]を使うべし。
<!--
Rule 4.  Fancy algorithms are buggier than simple ones, and they're much harder to implement.  Use simple algorithms as well as simple data structures.
-->

* ルール5: データはすべてを決定づける。もし、正しいデータ構造を選び、ものごとをうまく構成すれば、アルゴリズムはほとんどいつも自明のものになるだろう。プログラミングの中心は、アルゴリズムではなくデータ構造にある。
<!--
Rule 5.  Data dominates.  If you've chosen the right data structures and organized things well, the algorithms will almost always be selfevident.  Data structures, not algorithms, are central to programming.
-->

* ルール6: ルール6は存在しない。
<!--
Rule 6.  There is no Rule 6.
-->

ルール1と2は、[[ドナルド・クヌース]]の格言「早すぎる最適化は諸悪の根源である」を言い換えたものである（[[最適化 (情報工学)#最適化する時期]]も参照）。

[[ケン・トンプソン]]はルール3と4を「疑いがあるときは[[力まかせ探索|総当たり]]（brute force）を使え」と言い換えている。これらは設計哲学の[[KISS原則|KISS]]の例でもある。

ルール5は[[フレデリック・ブルックス|フレッド・ブルックス]]が以前に「[[人月の神話]]」で述べている。ジョン・ベントレーの ''[[:en:Programming Pearls|Programming Pearls]]'' にも同じ原則が述べられている。これは「スマートなデータを使うつまらないコードを書け」と短縮されこともある。また「データ構造が十分に良いものなら、それを扱うアルゴリズムは平凡であるべきだ」というガイドラインの実例でもある。

ルール6は[[モンティ・パイソン]]の「ブルース・スケッチ」をふざけて引用したのものである。

==ガンカーズ: UNIXの哲学==
1994年、マイク・ガンカーズ（[[X Window System]]開発チームの一員）は、UNIXで得た経験と、同僚プログラマーや他分野のUNIX利用者との議論を活かし、以下9つのUNIX哲学を創出した{{要出典|date=2023年9月}}：

#スモール・イズ・ビューティフル (小さいものは美しい)
#各プログラムが一つのことをうまくやるようにせよ
#できる限り早く試作せよ
#効率よりも移植しやすさを優先せよ
#単純な[[テキストファイル]]にデータを格納せよ
#ソフトウェアを梃子(てこ)として利用せよ
#梃子の効果と移植性を高めるために[[シェルスクリプト]]を利用せよ
#過度の対話的インターフェースを避けよ
#すべてのプログラムをフィルタとして設計せよ
<!--
#''Small is beautiful.''
#''Make each program do one thing well.''
#''Build a prototype as soon as possible.''
#''Choose portability over efficiency.''
#''Store data in flat text files.''
#''Use software leverage to your advantage.''
#''Use shell scripts to increase leverage and portability.''
#''Avoid captive user interfaces.''
#''Make every program a Filter.''
-->
以下の教義は重要性が比較的低いとされ、UNIX哲学として普遍的に合意されるものではなく、場合によっては現在も激しく議論されている（例：[[カーネル#モノリシックカーネル|モノリシックカーネル]]と[[カーネル#マイクロカーネル|マイクロカーネル]]）。

#好みに応じて自分で環境を調整できるようにせよ
#OSのカーネルは小さく軽量にせよ
#小文字の短い名前を使え
#森林を守れ
#沈黙は金なり
#並行性を考えよ
#部分の総和は全体よりも大きい
#[[パレートの法則|90パーセントの解決]]を模索せよ
#劣るほうが優れている (より悪いことは、より良いことだ)
#階層的に考えよ

==より悪いことは、より良いことだ（Worse is better）==
リチャード・P・ガブリエルは、UNIXの優位性のひとつは「より悪いことは、より良いことだ」（"Worse is better"）という哲学にあると述べている。ここではインターフェースと実装の'''両面が'''シンプルであることが、他のいかなる特性（正確さ、堅牢さ、完全さ）よりも重視される。

その一方で、以下のような疑問も投げかけている。例えば、もしI/Oやsleepなどのシステムコール（例：<code>read()</code>、<code>write()</code>、<code>open()</code>、<code>select()</code>）により、あるプロセスがカーネル内で長期間ブロックされているときに、そのプロセスに[[シグナル (Unix)|シグナル]]が通知されたら何を行うべきだろうか。システムコールが完了するまでの長い間（場合よっては永遠に）シグナルは遅延されるべきなのか。はたまた、カーネルはシステムコールをあとで再実行できるように状態を保存した上で一時中断し、シグナルハンドル、システムコールへと再復帰すべきか。いずれも時間はかかるがシステムコールを完遂する完全性を考慮したものである。

しかしながら、このようなケースでは[[ケン・トンプソン]]と[[デニス・リッチー]]は完全性よりもシンプルさを好む。聡明期のUNIXはシステムコールを終了させ、エラーを素早く通知する - ''Interrupted System Call''（システムコール実行中にユーザーが割り込みを発行）、エラー番号4（EINTR）。後にシステムコールは再開されない<ref group="注釈" name="example">現在のUnixではカーネルコードがユーザスタックで実行されない。また、I/O中のシグナルがこのようなふるまいであったのは初期のUNIXやSystemV（あるいは初期のLinux）のことである。4.3以降のBSDや現在のLinuxでは、全くI/Oが進行していない状態でシグナルが入った場合、シグナル処理が終わった後、中断されたI/Oが再開される。</ref>。この実装はI/Oシステムを設計、理解しやすくする事に利点がある。<!-- 以下は意味が不明瞭でありコメントとして削除した：圧倒的多数のプログラムは影響を受けない。なぜならこうしたプログラムはSIGINT/^C以外のシグナルを扱わず、経験もしないし、SIGINTが発せられたときには正確に終了（die）するからである。それ以外の少数のプログラム（ジョブ制御のキー入力を受け付けるシェルやテキストエディタのようなもの）のためには、システムコールの小さなラッパー（wrapper）を追加することができ、EINTRエラーが起こったらすぐにシステムコールを再試行できるのである。問題はシンプルな方法で解決される。 -->

==レイモンド: UNIXプログラミングの技法==
[[エリック・レイモンド|エリック・S・レイモンド]]は著書『The Art of UNIX Programming』<ref>Addison-Wesley刊 ISBN 978-0-13-142901-7、アスキー刊日本語版 ISBN 978-4-7561-4948-0</ref>で、UNIX哲学を "Keep it Simple, Stupid" （[[KISS原則]]、「シンプルでつまらないものに保て」）という工学哲学として要約した。いかにこの哲学がUNIXの文化的規範として適用されているか信念を述べている。しかしながら、以下のルールを違反した例も比較的簡単に発見できる。

;[[モジュール]]化のルール
:クリーンなインターフェースで接続されるシンプルなパーツを書け。
:プログラムは、単純な部品同士を明確な定義を持つインターフェースでつなぎ合わせたものとして書かれるべきだ。そうすれば、問題は局所的なものとなり、プログラムの一部は将来のバージョンで新機能をサポートするために交換することができる。このルールの狙いは、複雑で長くて読めないコードをデバッグする時間を節約することにある。
<!--
;Rule of Modularity: Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging code that is complex, long, and unreadable.
-->

;明瞭さのルール
:明瞭さは独創性よりも良い。
:開発者が最も意志疎通を図るべき相手はコンピュータではなく、プログラムを読み、保守を行う自分を含めた開発者であるかのようにプログラムを書くべきである。このルールは、将来そのコードを扱う人にとって、コードが読みやすく、理解しやすいものにすることを目的とする。
<!--
;Rule of Clarity: Developers should write programs as if the most important communication is to the developer, including him- or herself, who will read and maintain the program rather than the computer. This rule aims to make code readable and comprehensible for whomever works on the code in future.
-->

;合成のルール
:他のプログラムと接続できるようプログラムをデザインせよ。
:開発者は他のプログラムと簡単に通信できるプログラムを書くべきである。開発者がプロジェクトを、過度に複雑な一枚岩のプログラムではなく、小さくてシンプルなプログラムに分解することを目的とする。
<!--
;Rule of Composition: Developers should write programs that can communicate easily with other programs. This rule aims to allow developers to break down projects into small, simple programs rather than overly complex monolithic programs.
-->

;分割のルール
:[[機構と方針の分離|ポリシーをメカニズムから分離]]せよ。インターフェースをエンジンから分離せよ。
:開発者はプログラムのメカニズムとプログラムのポリシーを分離する必要がある。一つの方法として、プログラムをフロントエンドのインターフェースと、そのインターフェースが通信するバックエンドのエンジンに分ける等がある。メカニズムを崩さずにポリシーを変更できるようにし、結果的にバグの数を減らすことを目的としている。
<!--
;Rule of Separation: Developers should separate the mechanisms of the programs from the policies of the programs; one method is to divide a program into a front-end interface and back-end engine that interface communicates with. This rule aims to let policies be changed without destabilizing mechanisms and consequently reducing the number of bugs.
-->

;シンプルさのルール
:シンプルさを求めてデザインせよ。複雑にしなければならない場合に限り、複雑さを加えよ。
:開発者はシンプルなデザインを心掛けるべきである。プログラムを小さく分かりやすい協調性を持った部品に分割する方法を模索せよ。開発者が「{{読み仮名|緻密|ちみつ}}で美しく複雑な」だが、実際にはバグだらけのプログラムを書いてしまうことを防ぐためのものである。
<!--
;Rule of Simplicity: Developers should design for simplicity by looking for ways to break up program systems into small, straightforward cooperating pieces. This rule aims to discourage developers’ affection for writing “intricate and beautiful complexities” that are in reality bug prone programs.
-->

;倹約のルール
:開発者は大きなプログラムを書くことを避けるべきである。これは開発時間の過剰投資を防ぐことが目的である。膨大な作業の数々を破棄したくないというプログラム所有者の気持ちが原因で起こる。小さなプログラムは、最適化やメンテナンスが容易であるだけでなく、廃棄する事も容易である。
<!--
;Rule of Parsimony: Developers should avoid writing big programs. This rule aims to prevent overinvestment of development time in failed or suboptimal approaches caused by the owners of the program’s reluctance to throw away visibly large pieces of work. Smaller programs are not only easier to optimize and maintain; they are easier to delete when deprecated.
-->

;透明性のルール
:透明性を求めてデザインせよ。調査とデバッグが簡単になる。
:開発者は将来そのプロジェクトに参加する開発者が、自分の思考プロセスを明瞭に理解できるように書き、有効な入力と正しい出力を容易に識別できる入出力形式を使用することによって、可視性と発見性を設計する必要がある。デバッグにかかる時間を短縮し、プログラムの寿命を延ばすことを目的としてる。
<!--
;Rule of Transparency:Developers should design for visibility and discoverability by writing in a way that their thought process can lucidly be seen by future developers working on the project and using input and output formats that make it easy to identify valid input and correct output. This rule aims to reduce debugging time and extend the lifespan of programs.
-->

;頑丈さのルール
:頑丈さは透明性とシンプルさから生まれる。
:開発者は透明性と発見力を高める設計をすることで、堅牢なプログラムにする必要がある。理解しやすいコードは、複雑なプログラムでは予見できないような状況に対してストレステストを行いやすいため。開発者が堅牢で信頼性の高い製品を構築できるようにすることを目的とする。
<!--
;Rule of Robustness: Developers should design robust programs by designing for transparency and discoverability, because code that is easy to understand is easier to stress test for unexpected conditions that may not be foreseeable in complex programs. This rule aims to help developers build robust, reliable products.
-->

;代表のルール
:知識をデータに織り込め。するとプログラムのロジックをつまらなくて頑丈なものにできる。
:開発者は選択に迫られたとき、プログラムの手続き的なロジックよりも、データをより複雑にすることを選択すべきだ。なぜなら、人間にとって複雑なデータは、複雑なロジックに比べて理解しやすいからだ。プロジェクトに携わるどの開発者にとってもプログラムを読みやすくすることで、プログラムの保守を可能にすることを目的とする。
<!--
;Rule of Representation: Developers should choose to make data more complicated rather than the procedural logic of the program when faced with the choice, because it is easier for humans to understand complex data compared with complex logic. This rule aims to make programs more readable for any developer working on the project, which allows the program to be maintained.[6]
-->

;[[驚き最小の原則|最小限の驚き]]のルール
:インターフェースデザインにおいては、常に驚きが最小限であるようにせよ。
:開発者はユーザーが期待する潜在的な知識の上に構築されるプログラムを設計する必要がある。例えば、電卓のプログラムでは、'+'は常に足し算を意味するはずである。開発者が直感的に使いやすい製品を作ることを奨励することを目的とする。
<!--
;Rule of Least Surprise: Developers should design programs that build on top of the potential users' expected knowledge; for example, ‘+’ should always mean addition in a calculator program. This rule aims to encourage developers to build intuitive products that are easy to use.
-->

;沈黙のルール
:余計な出力をすべきではない。他の開発者にとってただ邪魔なだけである。
:開発者は不要な出力をしないようにプログラムを設計する必要がある。他のプログラムや開発者が、冗長な出力を解析することなく、プログラムの出力から必要な情報を選び出せるようにすることを目的とする。
<!--
;Rule of Silence: Developers should design programs so that they do not print unnecessary output. This rule aims to allows other programs and developers to pick out the information they need from a program's output without having to parse verbosity.
-->

;修復のルール
:失敗しなければならないときは、騒がしく、かつできるだけ早く失敗せよ。
:開発者は故障の原因が特定しやすく、診断しやすい、つまり「音を立てて故障する」プログラムを設計する必要があります。プログラムからの不正な出力が入力となり、他のコードの出力が検出されずに破損することを防ぐことを目的とする。
<!--
;Rule of Repair: Developers should design programs that fail in a manner that is easy to localize and diagnose or in other words “fail noisily”. This rule aims to prevent incorrect output from a program from becoming an input and corrupting the output of other code undetected.
-->

;経済のルール
:プログラマの時間は貴重である。プログラマの時間をコンピュータの時間より優先して節約せよ。
:現在のマシンサイクルは1970年代の価格と比較して相対的に安価であるため、開発者はマシンタイムよりも開発者タイムを重視すべきだ。プロジェクトの開発コストを削減することを目的とする。
<!--
;Rule of Economy: Developers should value developer time over machine time, because machine cycles as of the year 2013 are relatively inexpensive compared to prices in the 1970s. This rule aims to reduce development costs of projects.
-->

;生成のルール
:hand-hacking<ref>{{Cite web |title=hand-hacking |url=http://www.catb.org/jargon/html/H/hand-hacking.html |website=www.catb.org |access-date=2023-01-09}}</ref>は避けよ。
:開発者は手書きでコードを書くことを避け、代わりに抽象的な高水準プログラムを書いて、コードを生成する必要がある。ヒューマンエラーを減らし、時間を節約することを目的とする。
<!--
;Rule of Generation: Developers should avoid writing code by hand and instead write abstract high-level programs that generate code. This rule aims to reduce humans errors and save time.
-->

;[[最適化 (情報工学)|最適化]]のルール
:洗練させる前に原型（[[プロトタイプ]]）を作れ。最適化する前に原型が動くようにせよ。
:開発者はソフトウェアを磨く前にプロトタイプを作るべきである。開発者がわずかな利益のために過剰な時間を費やすことを防ぐことを目的とする。
<!--
;Rule of Optimization: Developers should prototype software before polishing it. This rule aims to prevent developers from spending too much time for marginal gains.
-->

;多様性のルール
:あらゆる「ただ一つの本当の方法」という主張は信じるな。
:開発者はプログラムが柔軟でオープンであるように設計する必要がある。このルールは、プログラムを柔軟にすることで、開発者が意図した以外の使い方を可能にすることを目的とする。
<!--
;Rule of Diversity: Developers should design their programs to be flexible and open. This rule aims to make programs flexible, allowing them to be used in other ways than their developers intended.
-->

;拡張性のルール
:未来に向けてデザインせよ。未来は思ったよりもすぐにやってくる。
:開発者は、プロトコルを拡張可能にし、他の開発者がプログラムのアーキテクチャを変更することなく簡単にプラグインできるようにし、プログラムのバージョンを表記するなどして、将来を見据えた設計をする必要がある。開発者が書いたコードの寿命を延ばし、実用性を高めることを目的とする。
<!--
;Rule of Extensibility: Developers should design for the future by making their protocols extensible, allowing for easy plugins without modification to the program's architecture by other developers, noting the version of the program, and more. This rule aims to extend the lifespan and enhance the utility of the code the developer writes.
-->

これら規範の多くはUNIXコミュニティの外でも受け入れられている――最初にUNIXが採用したときはそうでなかったとしても、後にそうなった。また、多くはUNIXコミュニティ独特のものではなく、UNIXコミュニティから生じたわけでもない。にもかかわらず、熟練のUNIXプログラマーはこれらの考え方を組み合わせたものをUNIXスタイルの基礎として受け入れる傾向がある。

==論争==
[[GNUプロジェクト]]による標準的なUNIXプログラムの代替（diffやfind等）がUNIX哲学に従うものであるのか、あるいはそれを誤解しているのかは議論の分かれるところである。おそらく、UNIXに古くから関わる人々のうちのいくらかは後者を主張するであろう。なぜならGNUプロジェクトのツール群はしばしばUNIXのものよりも十分に大きく、また機能も豊富だからである（[[GNU]]はコーディング標準において、いくつかの点でUNIXと同じにしないことを薦めている）。

GNU以前の1983年、ロブ・パイクはUNIXの基本的なツールについて、BSDによって拡張された機能のいくつか（代表例として挙げられたのは、cat に制御コードを文字に変換して可視化させる -v ）の仕様が、UNIX的でないとした批判がある<ref>http://harmful.cat-v.org/cat-v/</ref>。UNIX哲学に従えば、cat -v の機能は独立したフィルタで果たされるべきである。本来「連結」コマンドである cat が、単にストリームを読んで書くだけの目的に流用されることが多いとはいえ、それに加えてあれこれと機能を持つべきではないという考え方もある。

同様にして批判されたls コマンドのオプション：出力を表示される幅に合わせて整形する機能は十分に便利であるが、UNIX哲学に従えば column コマンドをパイプで繋ぐ必要があり、これは煩わしいと考える事もできる 。<!--同一のバイナリが違う名前で起動されると働きが異なる件について記述がありましたが、カットしました。多分、ls コマンドの議論に出力先により結果が違うこと（パイプが出力先だと整形が起きないこと）というのがあるので、そこからの連想だったのかもしれませんが、違う名前で起動されるコマンドというのは少し話が違ってくるはずです-->

==引用==
*「UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである。」 - [[デニス・リッチー]]
*「UNIXはユーザが愚かなことをするのを止めるために作られたのではない。小器用なことをするのも防いでくれるのだ。」 - ダグ・グウィン
*「UNIXはユーザフレンドリーだ。誰彼構わずフレンドリーになるわけではない<!--直訳：どのユーザにフレンドリーになるかに関して、UNIXは相手を選ばないわけではない-->だけだ。」- スティーブン・キング
*「UNIXを理解しない人々は、それを不十分に再発明することになるだろう」 - ヘンリー・スペンサー

==関連項目==
*[[Plan 9 from Bell Labs]]
*[[パイプ (コンピュータ)]]
*[[:en:The Elements of Style]] – UNIX哲学の着想の源の一つ。
*[[:en:The UNIX-HATERS Handbook]]
*[[ソフトウェア工学]]

==参照==
*''[http://cm.bell-labs.com/cm/cs/upe/ The Unix Programming Environment]'' by [[ブライアン・カーニハン|Brian Kernighan]] and [[ロブ・パイク|Rob Pike]], 1984
*[http://www.lysator.liu.se/c/pikestyle.html ''Notes on Programming in C''], Rob Pike, September 21, 1989
*''UNIXの1/4世紀'', Peter H. Salus, Addison-Wesley, May 31, 1994 (ISBN 0-201-54777-5、ISBN 4756136591)
*[http://www.faqs.org/docs/artu/philosophychapter.html ''Philosophy''] &mdash; from [http://www.catb.org/~esr/writings/taoup ''The Art of Unix Programming''], Eric S. Raymond, Addison-Wesley, September 17, 2003 (ISBN 0-13-142901-9、ISBN 4756149480)
*[http://citeseer.ist.psu.edu/schroeder77final.html Final Report of the Multics Kernel Design Project] by M. D. Schroeder, D. D. Clark, J. H. Saltzer, and D. H. Wells, 1977.
* ''UNIXという考え方―その設計思想と哲学'', Mike Gancarz, ISBN 4274064069

==脚注==
{{脚注ヘルプ}}
=== 注釈 ===
{{Notelist}}
=== 出典 ===
{{reflist}}

==外部リンク==
*[http://www.linfo.org/unix_philosophy.html The Unix Philosophy: A Brief Introduction] - by The Linux Information Project (LINFO)
*[http://www.joelonsoftware.com/articles/Biculturalism.html Joel on Software - Biculturalism]

{{DEFAULTSORT:UNIXてつかく}}
[[Category:UNIX|てつかく]]
[[Category:ソフトウェア開発哲学]]
[[Category:コンピュータの文化]]