背景
私たちのほとんどは、フィルタとパイプがUnixシステムの基礎であることに同意します。
パイプとフィルターは非常に強力なツールです。ほとんどすべてのUnixユーティリティはデフォルトで標準入力と出力ストリームを使用するため、パイプで使用できます。
Unix でユーティリティを実行するためのルールです。標準入力そして標準出力他の入力/出力ファイルが指定されていない場合。
grep
、、、、、、、、、および他as
の多くのユーティリティは、この規則に従うユーティリティです。sed
tr
perl
sort
uniq
bash
cmp
cat
しかし、多くのプログラミングユーティリティはこの規則を放棄しました。
入力を読む
最も明確な例はcc
(Cコンパイラ)です。
パラメータなしで呼び出すと、cc
次のメッセージが表示されます。
ryvnf:~$ cc
cc: fatal error: no input files
compilation terminated.
これが唯一の例ではありません。
ryvnf:~$ yacc
/usr/bin/bison: -y: missing operand
Try '/usr/bin/bison --help' for more information.
as
読み取りなどの低レベルユーティリティ標準入力基本的に。理由がわからない。
出力書き込み
これは出力にも当てはまります。
cc
基本的に実行コードをa.out
。パーサジェネレータは、yacc
生成されたパーサをy.tab.c
。
私にとっては、基本的に標準の入力/出力ストリームを使用すると、さまざまなユーティリティを簡単に接続できるという点で有利です。このパイプラインと同様に、中間ファイルを生成せずに yacc パーサーを実行可能コードに一度にコンパイルしますy.tab.c
。たとえば、次のようになります。
yacc parser.y | cc -o parser
私の質問
プログラミングユーティリティが他の多くのUnixユーティリティのようにデフォルトで標準ストリームを使用しないのはなぜですか?
未使用の動機は何ですか?標準入力ストリーム基本的に、これらのユーティリティは何ですか?
ノート私はあなたがcc
読むことができることを知っています標準入力使用してcc -x c -
。これはうまくいきますが、なぜ基本的にこれをしないのかという質問が残っています。
答え1
パイプは着信入力を処理できないため、ソースコードでは機能しません。処理が開始される前にファイル全体をロードする必要があります。コンパイルに複数のファイル(.hファイルなど)が必要な場合、状況はさらに悪化します。標準入力から読み取る場合は、パイプで接続するファイル間のファイル分割を指定するために必要なすべてのファイルをストリーミングする方法が必要です。問題はそこから大きくなり始めました。
パイプラインの基本的なアイデアは、一連の簡単な作業になるということです。コンパイルされたコードはいいえこれは簡単な作業なので、パイプラインの一部として設計されていません。パイプライン理論はまた、個々のコンポーネントの移植性を高めるために、パイプライン内のプロセス間のすべての通信がプレーンテキストで行われるべきであると述べています。定義によると、コードコンパイルに関連する出力cc
はモデルに適していないバイナリデータです。yacc
ld