はじめに
知っての通り NoSQL とは一般的には RDBMS ではないデータベース管理システムのことですが、実は 世界初の「NoSQL」は Unix シェルベースの RDBMS なのです。NoSQL は Unix 哲学に基づいており、標準入出力やパイプを使うフィルタコマンドや、SQL の JOIN や集合演算相当の機能を持ったコマンドセットとなっており、シェルスクリプトや awk や Perl で実装されており、データはすべてプレーンなテキストファイルに保存します。
それが「NoSQL: a non-SQL RDBMS」です。
注意 この記事は技術系の読み物（雑学）です。データベースの技術的な話はほとんど出てこないのであしからず。
ネタバレ
この NoSQL が誕生したのは 1998 年です。そして、みんなが知ってる NoSQL という言葉が誕生したのは 2009 年です。そういうことです。この二つは全くの別物です。（開発者自身が公式ページの「What NoSQL is not」でそう書いています）
この話は実は「日本語 Wikipedia の NoSQL」でさえ、ちゃんと書いてあります。
NoSQLという用語は1998年、SQLインタフェースを持たない軽量な関係データベースのオープンソースソフトウェアの名前として最初に用いられた。その著者Carlo StrozziはNoSQL運動について、「関係モデル全体と一線を画すものであるから、『NoREL』などと名づけられるべきだった」と主張している。
いや、実に気づきにくい。この文章が、皆が知っている NoSQL と本当に全く関係ない別のソフトウェアの話だったとは。
おそろしく分かりづらい文章。オレでなきゃ見逃しちゃうね。
・・・すみません。嘘です。ついこの間まで見逃してましたorz
このソフトウェアの開発者からしたらたまったもんじゃなかったでしょうね。自分が 10 年以上も前から使っていた「リレーショナルデータベースの NoSQL」という用語を、後からきた連中が「リレーショナルではないデータベース」という正反対の意味として取られたわけですから。
注意 この記事は「シェルスクリプトのデータ管理はどうすべきか？という」技術系の読み物（雑学）です。データベースの技術的な話はほとんど出てこないのであしからず。
Strozzi NoSQL とリレーショナルデータベース
世界初の「NoSQL」とは、近年の NoSQL 型データベースのことではなく Carlo Strozzi が開発したシェルスクリプト用のコマンドセットの名前です。紛らわしいので NoSQL という名前のソフトウェアを英語版 wikipedia のタイトルにしたがって「Strozzi NoSQL」と呼ぶことに・・・発音がわからなくて呼べないので調べたらストロッツィだそうです。最初に言っておくと、このプロジェクトは 2014 年の更新を最後に開発が終了しているようです。
NoSQL は、その単語から「SQL を使わない」という意味であり RDBMS を全否定しているように勘違いされがちですが、最近（？）では NoSQL は 「Not Only SQL」（SQL だけじゃない）の略として考えるようにと新しい意味の NoSQL という言葉を作り出した人たち（中心は Eric Evans ？）が言っているようです（参考 「NoSQL」は「Not Only SQL」である、と定着するか？）。そして以前のような NoSQL ブームは終わり、NoSQL の機能の一部は RDBMS へ取り込まれながら共存の道へと収束しました。まあどう見ても使い所が違うのでそりゃそうですよね。今だから言えることかもしれませんが。
それはそれとして私は Strozzi NoSQL の開発者である Carlo Strozzi が言うように、一般的な意味の NoSQL は「NoREL」（リレーショナルデータベースではない）の方がより正確だと考えています。例えば Google の BigQuery は、データの問い合わせに 標準 SQL を使いますがデータモデルはリレーショナルデータベースではありません。SQL を使う、使わないで、データモデルは決まりません。
開発者自身が語っているように Strozzi NoSQL は SQL を使わない RDBMS です。データモデルがリレーショナルデータモデル（グラフ型やドキュメント型などではない）に基づいているからです。データの保存形式を ASCII テキストファイル形式にして RDBMS の機能をコマンドとして実装しただけで、RDBMS のやり方、つまりテーブルファイルがあって JOIN して集計するなど RDBMS の発想で使うから RDBMS なわけです。一般に使われている意味の NoSQL は NoREL が正確な意味なので、たとえ SQL を使わなくても RDBMS の発想で使うならば、それは RDBMS であり NoSQL (NoREL) にはなりません。実にややこしいですね。
実際に Strozzi NoSQL にどのようなコマンドが実装されていたかは NoSQL command quick reference から見ることができます。また Unix コマンドを使って RDBMS 相当のことをやることに興味がある方は Documentation Index よりテーブル構造やデータ型、大きなファイルを扱う方法や並列書き込みやインデックスファイルなどの情報を見ることができるようです。
え？私ですか？技術のいくつかは参考になるかもしれませんが、私は Unix コマンドで RDBMS の真似事をやることに興味はないです。RDBMS 相当のことをするのであれば他の言語とちゃんとした RDBMS を使いますし、どうしてもシェルスクリプトでやりたいと思った時は私なら SQLite を使います。 SQL が使える CLI インターフェース (sqlite3 コマンド) を持っている上に NoSQL (JSON) 対応、サーバーレスで設定不要でインストールが簡単、トランザクションや排他制御の実装により信頼性が高く、膨大な数のテストコードと利用実績があって、POSIX 準拠のオープンソースで長いサポートと高い移植性と互換性があるからです。私の目的はデータベース管理システムの劣化版を自作することではなく、価値のあるソフトウェアを作ることなので、そんなものまで自作していたらいくら時間があっても足りないですし、自分で排他制御やトランザクションを実装して航空グレード (DO-178B) の SQLite クラスの品質と信頼性を実現できるとは思えません。 餅は餅屋、データベース管理システムはデータベース管理システムの専門家に任せるのが一番です。
Strozzi NoSQL に関するその他の情報について
- https://www.linuxjournal.com/article/3294
-
https://www.gnu.org/software/nosql/
- NoSQL は GNU パッケージではないが、以前は GNU サイトでホスティングされていた？
- http://www.troubleshooters.com/lpm/200704/200704.htm
Philosophy of NoSQL（Strozzi NoSQL の哲学）
Strozzi NoSQL の「Philosophy of NoSQL」のページで語られてる「Why NoSQL, in the first place ?」（なぜそもそも NoSQL なのか？）では、 Strozzi NoSQL が「コンピュータを使わない人にとっても簡単であり」（異議あり）、「私が知る限り、UNIX シェルほどパワフルで柔軟なデータベーススクリプト言語は他にありません。」（異議あり）と書かれています。また Strozzi NoSQL は「参照整合性、トリガー、ストアドプロシージャなどの、現在のほとんどの RDBMS に見られる機能を提供しません。」と書かれておりむしろデメリットのほうが気になります。更に言うならば、私がデータベースとして重要視してるのは、大容量データベースでも高速であることや、ネットワーク対応や分散データベースで大規模システムへスケールアウト出来ることや、どのタイミングで強制的に電源断しても問題ないような信頼性の高さで、しかもそういうことを何も気にすることなく開発できる生産性の高さを重視しますが、もちろんそんなものは Strozzi NoSQL や Unix コマンドでは実現できません。Unix コマンドと連携できる所は評価しますが、Unix コマンドとの連携であれば SQLite でもできます。
さて「Strozzi NoSQL の哲学」のページでは Strozzi NoSQL は論文「The UNIX Shell As a Fourth Generation Language」の概念に基づいており「この論文は、なぜ UNIX シェルがデータベースアクセススクリプトの優れたツールであるかを示しています。」と書いてありました。この論文ですが実に偏った内容です。はっきり言いますが UNIX シェルがデータベースアクセススクリプトに優れているなんてことはありえません。 むしろ正反対です。私はシェルスクリプトと Unix コマンドでデータ管理する場合の多くの問題点を語ることが出来ます。（それは別の機会に）
そして私の興味の先はこの論文へと向かいました。
論文 The UNIX Shell As a Fourth Generation Language
日本語に訳すと「4GL（第四世代言語）としての UNIX シェル」で、どうやら 1991 年に発表された論文のようです（参考 Hacker News や The Art of UNIX Programming で 1991 年と記されています）。4GL とはまた懐かしい用語ですね。
4GL、第四世代言語とは第三世代言語の次のプログラミング言語のことで、今の多くのプログラミング言語は第三世代言語と言われています。具体的には、COBOL、C 言語、C++、Java、JavaScript などおおよそなんでもです。これでは第三世代言語が何のことかわからないので逆に他の世代を説明した方が良いでしょう。第一世代言語は機械語です。第二世代言語はアセンブリ言語です。
では第四世代言語とは何かというと「第三世代言語を超えるなにか」です。そして第五世代言語は「更にその先の未来の夢の言語」です。なんだその適当な解説は？と思われるかもしれませんが、要するに第三世代言語というのは高級言語が登場した頃の 1970 年代から 1990 年代に使われていた、将来を夢みて作られた言語の分類で Web 2.0 のようなものです。一応エンドユーザーに近い言語、生産性がもっと高い言語という扱いですが、厳密な定義はなく、人それぞれバラバラで、自分たちが作ったコレが 4GL だと主張しており、実質的にマーケティング用語と言っても過言ではない用語です。とうの昔に消えた用語だと思っていましたが、Wikipedia によるとどうやら最近ではローコードを 4GL と呼んでいる場合があるようです。懲りないですね。
まあこんな用語であることをなんとなく知っていれば「4GL としての UNIX シェル」というタイトルの論文に、うさんくささを感じるのも仕方ないでしょう？ で、この論文「The UNIX Shell As a Fourth Generation Language」ですが結論を言うと営利企業の宣伝です。まあ企業が絡んでようがなかろうが、おかしな論文はおかしい論文でしかありませんが。（念の為ですが私個人の意見です）
論文の冒頭に Revolutionary Software と書いてありますが、この会社は Database of Databases によると Strozzi NoSQL と同じようなソフトウェアである /rdb（bash 実装？）を開発していた会社です。ちなみにこの情報へは Strozzi NoSQL のページからリンクされていた How Not To Re-Invent The Wheel（車輪の再発明をしない方法）経由でたどり着きました。車輪の再発明ってなんですかね？ SQL 相当のコマンドを作ることですかね？（すっとぼけ）この会社は設立が 1984 年でプロジェクトの終了が 2016 年のようです。この会社が現在どうなったのかまでは調べていませんが、少なくとも公式サイト http://www.rdb.com/ （過去の履歴）はアクセス不可能ですね。
たとえ論文があったとしても、誰がどういう立場で書いた論文なのかという背景を見極め、特にビジネス的な利害関係が認められるなら、論文の内容を真に受けず自分で検証しなければいけないという良い例です。この話は「なぜソフトウェア論文を書くのは難しい(と感じる)のか」という論文が参考になります。こちらの論文には大変良いことが書いてあるので、すべての人に読むのをおすすめします。
そして、へんてこなシステムであるほど、たくさんの論文が書ける。そいつを動かすために乗り越えなければならなかったいろんな障害について書けるからね。
言うまでもなく科学的手法では追試が重要です。提唱された理論や手法は、実用上、有効であることを第三者が確かめるまでは仮説に過ぎないからです。
関連情報 書籍「Unix Relational Database Management」この本は Strozzi NoSQL が参考にしており /rdb の開発者が書いているようです。私は中身を読んでいません。で、この本の情報を検索していて見つけた On /RDB (GitHub) は、もしかしたら /rdb を再実装しているのかもしれません。ともかくこれでコマンド名がわかったので情報を検索しやすくなりました。でもそれはいつか気が向くことがあればですが。
テキストファイル・パイプ・コマンドは遅い
それにしても、この「The UNIX Shell As a Fourth Generation Language」もそうですが、なんでそんなにテキストファイルやら Unix コマンドやらパイプを過大評価したがるんですかね？テキストファイルは既存の Unix コマンドがテキストファイルにしか対応してないからそれしか選択肢がないだけだし、パイプはグルー言語（他の言語で作られたプログラムに頼る言語とも言える）のシェルスクリプトにとっては重要な機能であることに間違いはないですが、OS が提供するたかが一機能にすぎません。その気にあれば他の言語でもパイプは使えます。もしパイプが本当にそんなに凄いものなら他の言語でも組み込まれているはずでしょう？
パイプで並列処理とか言ったって、他の言語ならもっと良い OS の API （スレッド API 等）が使えるわけで、だからわざわざパイプで並列化なんてやらないわけです。他の言語より短く書けて優れてると分かりやすいシェルスクリプトの機能がパイプぐらいしかないからでしょうか？そしてそのような些細なことのために、みんな大きなテキストファイルの更新や検索が遅い問題に苦しめられています。テキストファイルやパイプはデータベースにとっては適切ではない技術だというなによりの証拠です。GUI や GPU を使う機械学習などに Unix 哲学が適合しないのと同じように、データベース管理システムにも Unix 哲学は適合しません。Strozzi NoSQL と /rdb の歴史がそれを証明しています。
テキストファイル・パイプ・コマンドは便利なものですが、遅いのです。それ一つあれば十分というような万能な道具なんてありません。状況に応じて適切な道具を使わなければ失敗します。
失敗から学ぶシェルスクリプトで高度なデータ管理を行うことの筋の悪さ
Strozzi NoSQL と Revolutionary Software の /rdb の一番の敗因は NoSQL と /RDB という紛らわしい名前 他のデータベースソフトが内部形式にバイナリを使っている理由を過小評価してしまい、制限の大きな単純なテキストファイルを選んでしまったこと でしょう。テキストファイルでもリレーショナルモデルを表現することは可能ですが「データベース管理システム」には「管理システム」が必要不可欠です。単純なテキストファイルと Unix コマンドでは管理システムの実装は困難です。
テキストファイルであれば既存の Unix コマンドが直接使えるというメリットはありますが、SQL は Unix コマンドが不要となるほどの機能を持っているわけで Unix コマンドが使えることにメリットはありません。また SQLite のようにコマンドのインターフェース（標準入出力）さえテキスト形式であれば、内部形式までテキストファイルにする必要はなかったはずです。例えば cat の代わりに zcat を使えばファイルがバイナリ（圧縮）形式であったとしても透過的に Unix コマンドをパイプでつなげることができるでしょう？
パイプは素晴らしい概念ですがパフォーマンスにおいては最高のものではありません。パイプ間通信でボトルネックが生じます。例えば 1GB のデータをパイプでつないだ 5 つのコマンドで処理する場合、4 つのパイプライン通信（標準出力と標準入力のためのシステムコール）を行うということになります。それぞれのコマンドで行う処理が小さいとしたら無駄にデータ転送をしているだけです。パイプはストリーミング処理でもあるのでデータに対してランダムアクセスが出来ません。これもパフォーマンス低下の大きな原因の一つです。もし先程の例でデータが 1 GB あるとして、1 バイトのデータ書き込みを行う場合でも 1 GB のデータ書き込みが必要になります。途中の 1 バイトだけをピンポイントで書き換えるということが出来ないのです。
もう少し具体的な例を出すと、ユーザーが指定した条件で「データ検索＋ソート」して画面にデータ出力するウェブアプリがあったとします。この場合、全データの検索（データ読み込み）を行い、さらにソート処理が必要になります。Unix コマンドの sort コマンドはメモリを消費しない形で最適化されておりマージソートというアルゴリズムがデフォルトで使われています。パイプの欠点の一つは最終的なデータ量が事前にわからないことでデータ量に応じて最適なアルゴリズムを選択するということが出来ません。そしてマージソートはメモリを消費しない代わりに一時ファイルを使用します。つまり 「検索とソート」という処理にファイル書き込みは必要ないように見えても、実際には全データ分のファイル書き込みを行っている （sort コマンドを使う場合）ということになります。事前にソートしておくという考え方もありますが、ソート条件はユーザーの入力で変わるので条件の組み合わせの数だけデータ量が倍増します。一般的なデータベース管理システム＝ミドルウェアというのは常に起動していて大量のメモリを活用する（例えば大量のメモリでソート済み状態をキャッシュする）ことで高いパフォーマンスをだすことが出来ますが、毎回プロセスの起動と終了を繰り返すシェルスクリプトと Unix コマンドの仕組みではそういったこともできません。
Unix コマンドがデータベースに勝るのは条件なしの全件シーケンシャル処理ぐらいだけです。だから全データをバッチ処理するようなものなら、かろうじてシェルスクリプトでも対応可能ですが、短時間で答えを返すレスポンスタイムが重要な処理は苦手です。根本的な原因はテキストファイルにありますが、先程指摘したとおり Unix コマンドをパイプでつなぐというやり方にも大きな問題があります。ようするにデータベース管理システムのようなものは、テキストファイルを使わずパイプが必要ない一枚岩のソフトウェアで作るのがよいということです。実際に現在第一線で使われているデータベースソフトウェアはすべてそのような設計になっています。
それだと Unix 哲学に反すると反論が返ってきそうですが、そもそも Unix 哲学は「哲学」であって万能の理論などではありません。 RDBMS は数学的な「理論」に基づいて作られたものですが、Unix 哲学というのは基本的な方針はあったとしても「人それぞれで違っている考え方のこと」です。哲学は正しい答えがあるようなものではなく、Unix 哲学が当てはまらない例などいくらでもあります。それをちゃんと言えて初めて Unix 哲学を理解したと言えます。Unix 哲学が当てはまらない点や時代に合わない点など、問題点を指摘できないならば Unix 哲学を理解できてないというのと同義です。
シェルスクリプトは他にも OS の API を実行するまでが遠いという問題があります。他のネイティブコードを生成するプログラミング言語やミドルウェアと呼ばれる専門ソフトウェアは、一般的に OS の API を直接呼び出して高いパフォーマンスを実現しています。しかしシェルスクリプトはパフォーマンスよりも簡単に書けることを目的としており、OS の API を呼び出すまでに多数のレイヤーが間に入ります。 具体的には「シェルスクリプト」→「シェル（シェルスクリプトのインタプリタ）」→「Unix コマンド（場合によっては awk のような別の言語のインタプリタ）」→「OS の API」のような形です。
シェルスクリプトと Unix コマンドのネットワーク通信のサポートの欠如はこの問題に拍車をかけます。その他のプログラミング言語では、ライブラリを通して OS が備えるソケット API を呼び出しますが、シェルスクリプトではこれも起動が遅いコマンド（wget や curl）経由で間接的に呼び出すしかありません。これでは直接 OS の API 呼び出せる他のコンパイル型言語やミドルウェアに性能面や機能面で太刀打ちできるわけがありません。 OS や Unix コマンドが（シェルスクリプトではなく）C 言語で作られているのはそれ相応の理由があるということです。もちろん今は Unix 時代とは違って C 言語よりも生産性も移植性も高い言語があり C 言語で作らなければシェルスクリプトを超えられないということはありません。
他にもシェルスクリプトには多数の問題があります。結局の所、ネットワークが必要な大規模システム、ミッションクリティカルなシステム、ビッグデータを扱うシステム、そういったものをシェルスクリプトと Unix コマンドで行うのは筋が悪いという結論にならざるを得ません。もちろんシェルスクリプトでもこれらの問題を解決する方法を頑張って実装すればある程度は改善できますが、そんな所に膨大な開発コストをかけるメリットは実際にありましたか？机上の空論ではなく数字で証明できましたか？という話です。
さいごに
まず、人々が知っている NoSQL とは別の Strozzi NoSQL というものがあることを紹介しました。これは初学者が間違って Strozzi NoSQL の情報にたどり着いてしまって勘違いすることがないようにです（wikipedia などに載ってますからねぇ…）。そして論文「The UNIX Shell As a Fourth Generation Language」は私個人の意見として企業が開発したソフトウェアの宣伝が目的だろうと結論づけました。これをどう捉えるかはおまかせします。
シェルスクリプト、そして Unix コマンドは他の言語を使うプログラマから何かと嫌われがちですが、作業を自動指したりするには便利なもので適切な用途であればプログラミング言語を使うよりも素早く目的を解決することが出来ます。なのですべてのプログラマはシェルスクリプトを学ぶべきだと私は考えますが、それでも RDBMS の完全なる代替として使えるようなレベルのものではありません。
Strozzi NoSQL と /rdb という二つの Unix シェルベースの RDBMS がプロジェクト終了となっていることからも、シェルスクリプトと Unix コマンドを使ってデータベース処理を行うというのが悪手であるというのは明らかです。それでもシェルスクリプトでデータ管理をしたいのであれば SQLite を使うことをおすすめします。（参考記事 なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決する）
SQLite は Strozzi NoSQL や /rdb とは違い、多数の Unix コマンドを覚えて組み合わせたりファイル構造やディレクトリ構造を設計するという大変で作業が不要です。データ管理のインターフェースに本物の SQL を採用した sqlite3 コマンドだけを使うという点で考え方が大きく異なっています。
SQLite は移植性と互換性が担保されており OS 依存の書き方をしないようにするなどの気を使わなくても、全く同じ書き方ですべての環境で動作させることが可能なのでシェルスクリプトの移植性の悪さを大きく軽減できます。SQL はデータ管理に特化した宣言型言語であるため、高度なデータ管理をシンプルで分かりやすく記述することができる上に、トランザクション管理や排他処理なども組み込まれています。また SQLite そのものは POSIX 準拠（ANSI C で規定された僅かな API しか使っていない）で、OS の API を直接呼び出せる C 言語で作られているため、OS の API を呼び出すまでの無駄が多いシェルスクリプトよりも圧倒的にパフォーマンスが優れています。組み込み用の C 言語ライブラリとしての使い方が中心で Android や iPhone、macOS など何十億というデバイスに組み込まれており、ソフトウェアの将来性の心配がないどころか、もはやインフラになっています。SQLite は "クライアント・サーバー型ではない" データベース管理システムの勝利者です。（関連記事 利用者は数十億人！？ SQLiteはどこが凄いデータベース管理システムなのか調べてみた）
SQLite はクライアント・サーバー型ではないのでさすがにクラウドとか大規模システムには対応できませんが、将来的にシステムが大きくなった時でもクライアント・サーバー型の RDBMS に移行しやすい可能性があり、RDBMS と SQL は汎用的な技術なので属人化しづらく（特定企業の独自技術ではないので外部から使える人を雇える）、技術者が入れ替わっても長い間メンテナンス可能な持続可能なシステム開発を行いやすいというメリットもあります。しかもこれら高度なソフトウェアを使うのに月々の高額なライセンス料は不要です。完全に無料で使うことが出来ます。面倒な利用契約も不要なので、今すぐ評価を開始することが出来ます。試しに使ってみて、もし自分たちのユースケースに合わなければその時は使うのをやめればいいのです。
20 年ぐらい前はもしかしたら Unix コマンドの方が SQL を知っている人よりも多かったかもしれませんが、おそらく今は逆に SQL を知っている技術者の方が多いでしょう。そのため「みんな知っている Unix コマンドを使った方が学習コストが低い」というメリットはありません。エンドユーザーに近い人であれば Unix コマンドの方が覚えることが少なくて簡単に感じるかもしれませんが、ソフトウェアエンジニアである私達やデータ管理そのものは RDBMS の方が柔軟で使い勝手が良いと感じます。その理由は RDBMS がコンピュータ科学者であるコッド博士によって数学的な理論に基づいて作られたものだからでしょう。さらにクラウドなどへの対応など技術者としての応用の幅が広いのもメリットです。
過去の歴史から学び、どのようにシェルスクリプトを活用すれば最大の効果を上げられるかを私は追求していくつもりです。そしてシェルスクリプトから覚えなきゃいけない無駄なバッドノウハウをなくし、もっと簡単に誰でも使えるものへと変えていくつもりです。シェルスクリプトは最高の言語ではありませんが、プログラマやそれ以外のエンドユーザーに近い人でも普段の作業を素早く改善することができるため学ぶ価値が高い言語です。シェルスクリプトかそれ以外の言語かの二択ではなく、両方を学びシェルスクリプトのパワーを他の言語にプラスするのです。元よりシェルスクリプトは他の言語と組み合わせて使うために作られた言語です。
「シェルはカーネルの周りにある」という例のアレの元ネタ？
これは完全に別件の話で、私の個人的なメモです。Unix Relational Database Management の著者の Rod Manis は Unix Shell Programming Language という本も書いているようで、Bourne Shell 自習テキスト によると、もしかしてこの本が例のアレの元ネタですかね？
It is called the shell, beacuse, like the shell of a nut or an egg, it is the part that we see from the outside. The inside part is called the kernel. The shell takes to us and to the kernel.
「それは、胡桃や卵の殻のよ うに、外から眺める部分なので、シェル（殻:shell）と呼ばれている。内部は核 （カーネル:kernel）と呼ばれる。シェルはカーネルと我々との仲立ちをする。」
kernelとはオペレーティングシステムの中枢で、プロセスやメモリ、ファイル等の 管理を行う部分です。unix上で何か仕事をする時には必ずお世話にならなければな らないものですが、ユーザ側からkernelに働きかける手段はシステムコールのみで す。プログラムを書くのでしたらシステムコールを操れますが、対話形式ではシェルを通す以外触れる方法がありません。シェルを通して備え付けのコマンドなり、自分の作ったプログラムを起動して初めてユーザはkernelへなんらかの指示を出すことができるわけです。プログラムを書かないユーザにとってはシェルこそがオペレーティングシステム、あるいはコンピュータそのものに見えますから、シェルを 使いこなすことがそのままコンピュータを使いこなすことになるわけです。
うーん、なんか変な所でつながったなぁ。
- ユーザ側からkernelに働きかける手段はシステムコールのみ
- プログラムを書くのでしたらシステムコールを操れます
- 対話形式ではシェルを通す以外触れる方法がありません。
- シェルを通して備え付けのコマンドなり、自分の作ったプログラムを起動して初めてユーザはkernelへなんらかの指示を出す
- プログラムを書かないユーザにとってはシェルこそがオペレーティングシステム、あるいはコンピュータそのものに見えますから、シェルを使いこなすことがそのままコンピュータを使いこなすことになるわけです。
後半は Bourne Shell 自習テキストからの引用です。「プログラムを書かないユーザにとってはシェルこそがオペレーティングシステム」この言い方なら理解できます。シェル（シェルスクリプト）は OS （カーネル）から最も遠くてユーザーに最も近い所にあるものなんですが誤解を招くようなおかしな図がでまわっています。元々はまともな内容だったのに、引用されて情報が劣化して勘違いが広まった可能性が微レ存？