csh & tcsh work historical and contemporary approaches

河本孝之(Takayuki Kawamoto)

Contact: takayuki.kawamoto (at) gmail.com.
(You can send me more secure email with my public key to another email address.)

ORCID iD iconORCID, Google Scholar, PhilPapers.

First appeared: 2019-03-20 17:30:21,
Modified: 2020-03-27 17:26:43,2020-07-24 14:09:50,
Last modified: 2020-08-16 11:28:45.

This website is not an archive of sources and documents for csh/tcsh shells.

※ なお、当サイトでは他のコンテンツにリンクする「目次」のようなものをページの先頭には書いていないので、他のコンテンツはページの末尾にある「その他の記事」という個所からご覧ください。

このコンテンツについて

このコンテンツは、UNIX-like operating systemシェルとして長らく使われている “C shell” (csh) と、その改変プログラムの “TC shell” (tcsh) を主に扱っています。UNIX だけを扱うわけではありませんし、csh や tcsh だけを扱うわけでもありませんが、サイトのコンテンツとして多くを占めることになるのは、UNIX-like な OS(特に僕が会社で使っている FreeBSD)で動作する、csh と tcsh に関するウェブページとなるでしょう。

もともとは FreeBSD に関連するドキュメントを書いていたのですが、FreeBSD のディフォールト・シェルである tcsh について調べると、非常にリソースが少なく、また色々なサイトでバラバラに扱われているため、できるだけリソースとしてまとめた資料サイトを作ることにしました。そして、tcsh の元になった記念すべき csh についても参考になるサイトが限られていて、しかもサイトが古くて archive.org にしかバックアップされていない事例もあり、現行のサイトも忘れられてしまう恐れがあったので、もともと考古学少年でもあったからか、丁寧に調べて情報を残しておこうと思ったわけです。そして 2019 年から1年ほど tcsh.work というドメインを取得して、csh.tcsh.work というサイトでコンテンツを公開していましたが、別のサイトで運営する意義も感じられなくなり、そして殆どアクセスもなかったので、2020年の8月にリニューアルした MarkupDancing へ統合することとしました。

なお、僕は当サイトで “historical approach” として csh や tcsh の記録やリソースを集めて紹介するという、或る種の懐古趣味的なアプローチだけではなく、csh や tcsh の設計思想やスクリプトを書くときのテクニックなどを現在の OS 運用に活用できる方法がないかどうかも探して紹介するという “contemporary approach” も採用します。

実のところ、僕の心境や動機としては、上に書いたことだけが理由なのではありません。僕は、過去の人々の実績をまじめに勉強して消化してこそ、新しく何かを考えたり、次のステージに進むための《歴史という正統性に支えられた責任や権利》を得るのだと考えています。

これはあくまでも希望ですが、僕の今後の予定として csh / tcsh のソースコードを読み込んで、UNIX のシステム・プログラミングについても取り上げたいと思っています。また、僕自身がウェブサイトのオンライン・アプリケーションを書いたり情報セキュリティのマネジメントに従事しているため、システム開発やセキュリティという観点からもケース・スタディとして csh / tcsh のソースコードやシェル・スクリプトの実例を批評することも念頭に置いています。こうしたことは、プログラムやソフトウェアが新しかろうと古かろうと一定の成果を上げられる「科学」あるいは「仕事」なのであり、僕は会社では RUST のような流行のプログラミング言語を勉強してもいますが、コンピュータ・サイエンスや IT の原則に興味がある人間にとっては、どちらからでも成果を上げられるでしょう。

冒頭に戻る

About the time zone for all webpages

Any notation for date and time at here should be written in a format as “YYYY-MM-DD hh:mm:ss” and its time zone (TZD) is omitted, though it must be in “+09:00” (JST = Japan Standard Time.)

冒頭に戻る

当サイトで使う登録商標について

冒頭に戻る

Q & A (virtually)

特に断り書きがない場合は、いわゆる「想定問答」です。“frequently asked” でもなんでもないので、僕が言いたいことを言うために自作自演しているにすぎません。

Cシェル(csh)を使ってはいけないという文書が20年前から出回っているというのに、どうしてそんなシェルのサイトを作るのか。
当サイトの趣旨で説明したように、まず csh という歴史的に一定の役割を担ったプログラムについて、僕は “historical approach” を採用して情報を収集し、それなりに体系立てて公開しようとしています。csh を、これからコンピュータで何かをしようという人たちに使ってもらいたいという目的でサイトを作っているわけではありません。しかし、あらゆる歴史的な事実にも言えることですが、過去にわれわれが間違ったことをしたり不十分な成果しか上げられなかったという評価があるからといって、それらを無かったかのように無視してはならないのです。それは第一に間違いをわれわれ自身が見つけ、改良してきたという業績も無視することになり、誰かが間違ったという事実だけではなく、誰かがそれを吟味して批判したり改良したという事実も含めて、歴史というものを冒涜する行為だと言えます。
しかし、僕は当サイトで過去の遺物を展示することだけを意図しているわけでもありません。あまり検討されていないことですが、上記の問いのような「Cシェル(csh)を使ってはいけない」という幾つかの文書があるのはいいとして、ではそれが本当に欠点なのかどうかを確かめたり、現在は他のシェルでどう改められているのかを、ソース・コードの解析というレベルで議論している人が、いったい世界中にどれほどいるのでしょうか。そして、csh や tcsh のソースを改変できる余地があるのかないのかを、もちろんコミットする必要が無くても議論している人はいるでしょうか。そういうところまで丁寧に扱ってこそ、初めて或るプログラムを使うべきではないと公言できるものです。そういうところまでやっていない大半の人々は、単にそういう文書(のタイトル)を目にして、csh を遠ざけているだけではないでしょうか。では、実際に “harmful” などと言われているのが本当なのかどうか、検証するようなサイトがあってもいいでしょう。そうしてこそ、僕らは技術としても文化としても次の段階に進めるのだと思います。僕は、このような取り組み方を “contemporary approach” と呼んでいます。
それぞれのシェルをどう呼んでいるのか。
当サイトで僕自身が書く文章においては、Bill Joy が最初に開発したシェルを “csh” として表記し、Ken Greer が TENEX (TOPS-20) という OS のコマンドライン・インタープリタから着想を得て手を入れたシェルを “tcsh” と表記しています。“csh” はシェルを起動するコマンド名であってシェルの名前ではないと思うかもしれませんが、たとえばレッサーが [Lasser, 2000: 67] の脚注で書いているように、「このことは、Unix のシェルが二つの名前を持っているということを指摘するのに打ってつけの事例だと思えます。つまり、これらのシェルには『実名(“real names”)』と、シェルを起動するために打ち込むコマンドの名前という二つの名前があるわけです。」というわけなので、シェルの名前としてコマンドの名前を使っても、特に何か誤解を招いたり不当となるわけでもないでしょう。
では、それぞれのシェルをどう呼んでいるのでしょうか。“-sh” は、おおむね “shell” と発音されているようなので、“csh” が “see shell (C shell)” と発音されていることに疑問を覚える人は殆どいないでしょうが、“tcsh” については、[Peek, O’Reilly, and Loukides, 2002: 10] では “T-shell” と表記していたり、あるいは “tee see shell” と表記しているページがあったりします。この手の発音ネタは、頻出の話題であるにも関わらずコンセンサスがなかったりすることもあるので、FAQ になっておらず何度でも持ち上がることがあります。
どうしても気になる方は、最初に開発した人がどう呼んでいたかをメールやカンファレンスでの懇談で尋ねたらいいだけだと思うのですが、開発者の当人たちであっても、そういうことに何か decisive というか決定的な影響を与えようとすることを「愚か」だと思う人もいます。僕も、はっきり言ってこういう話題は齟齬が生じない限りはどうでもいいと思っています。僕が専攻している科学哲学でも、“van Fraassen” や “Putnam” や “Kyburg” といった研究者の名前の発音は人によって違うこともありますし(僕はそれぞれ「ファン・フラッセン」「プトナム」「カイバーグ」と表記したり呼んでいます。国内では「ファン・フラーセン」「パトナム」「キュバーグ」といった表記もあります)、当人が特にこだわっていないこともあります。とりわけアメリカのような移民の国では、そんなことにこだわる暇があったら別のことをした方がいいと考える人も多いわけで、僕も「かわもとさん!」と呼ばれようと「こうもとさん!」と(間違って)呼ばれようと、僕を呼び止めていることが分かれば、その人を無視したりしません。そして無視せずに応じたなら、言葉で相手に呼びかけるという相手の目的は果たされているのですから、それでいいではありませんか(もちろん、正しくは「かわもと」であることも伝えますが)。
「ドキュメントのアーカイブではない(This website is not an archive of sources and documents for csh/tcsh shells)」と書いているのはなぜ?
もちろん可能であればドキュメントを転載させてもらったり、翻訳させてもらうかもしれませんが、許可を受けた文書だけを率先してアーカイブすると、できるだけ多くのリソースを無差別にアーカイブするとしても偏りが生じるかもしれません。よって、僕が当サイトで自らの見識や判断による理由や動機があって、何かを考察するにあたり転載したり訳出しておくべきだと決めて許可を受けた(あるいは public domain や Creative Commons として公開されている文書にも言えることですが)文書だけを当サイトで公開します。転載や翻訳の許可を受けた文書であるかどうかと、その文書の内容の是非(とりわけ、僕がその文書の主張を支持しているかどうか)とは関係がないと冷静に受け止められる人だけがアクセスしてくるわけではないと思うので、何か特定の意見に偏った文書ばかりをアーカイブしたり訳していると思われは困りますから、僕自身が自分のコンテンツを制作するに当たって必要だと判断したわけでもない文書を、アーカイブするというだけの目的で転載したり翻訳したりはしないという方針を取っています。
マイナーな、あるいは実務上の補足的な理由を挙げると、オンラインで公開されている多くの文書やメール等のメッセージは、転載したり翻訳してもいいかどうか、ライセンスを明示していないことも多いからとも言えます。日本の著作権法や条約の範囲で「フェアユース」の法理を個人が勝手に立てて無断の転載や翻訳を行うのは、僕は法治国家の成人として単純に不見識だと思います。大人がそういうことをオンラインで、若者や子供も閲覧するようなウェブサイトで無邪気に実行するのは、ただたんに恥ずべきだとしか思えません。そして、そういう理由があるので、翻訳や転載の許可を取るために連絡する方法が分からないような人も多く、もちろん中には学術文書として所定の金額を支払う必要のある文献もあるため、僕が承諾を受ける暇やお金があるかないかという瑣末な理由で転載したり翻訳したりしなかったりするという違いが生じるのは、やはりアーカイブとしては偏っていますし、考えようによってはそういうアーカイブなら無いほうが公正だとすら言えます。
また、別のマイナーな理由もあります。とりわけ、日本の技術者やアマチュアの多くは、海外のリソースを紹介したり取り扱う際に、漫然とテキスト・データとしてコピーしたままサーバへ置くとか翻訳文書を公表するだけに留まることが多く、もちろんそれらの仕事も敬服に値する成果が数多くありますが、やはり知識や経験の共有とか継承という意味では不十分なアプローチだと思います。学術文書にも言えることですが、“discussion”(誰かと交わす「議論」ではなく「考察」という意味)なくして十分な成果とは言えません。したがって、当サイトのコンテンツを作成するために多くの書籍や論文、メーリング・リストあるいはニューズ・グループのメッセージ、そしてウェブページなどをダウンロードしたり購入して保管していますが、それをそっくり誰かへバケツリレーよろしく渡すだけで済むような仕事であれば、やや傲慢な言い方かもしれませんが、僕がするほどのことではないと思うわけです。
更に加えて、「無断リンクの禁止」を明示的に訴えているページも、いまだにあります。あるいは、部外者に公開する意図がないページを、検索でヒットしたというだけで利用するのはやめてほしいと訴えているページもあります。たとえば東北大学の齋藤理一郎氏のサイトに「csh 入門」というタイトルで何ページかの解説記事がありますが、詳しく齋藤氏のサイトを見ると「道に面している家の窓が開いているからといって、全ての人に中を 見せる為に開いているわけではありません」とあり、公開を意図されているのかどうか判断ができないため、このページは当サイトのリソースとして扱っていませんし、齋藤氏の一文を閲覧した後は、そもそもウェブページに全くアクセスしていないため、私が個人として読むべき価値があるかどうかの判断すらつかないため、紹介しようがありません(論理的には、そう判断して行動する他にない)。このような事情もありますので、決して全てのリソースが利用できるわけでもなく、したがってオンラインで公開されていたり見つけられるページを全て納めるどころかリンクすることすら不可能な場合もあるわけです。
以上の理由から、僕はこのウェブサイトを csh と tcsh に関するアーカイブとして公開したり制作・運営する意図はありません。できるだけ多くの文献を紹介したり翻訳したいとは思っていますが、あの(或る意味で敬愛すべき)ジェイソン・スコットのようなアプローチはとっていないということです。もちろん、彼ら Internet Archive のように見境なくすべてのデータを収集して保存するというアプローチにも利点はあります。上記で書いたように、僕はこのサイトで、知識や経験として何を継承するべきかという点について、僕なりの見識で情報を取捨選択しています。したがって、そういう意味で当サイトのコンテンツとして何を公開しているかという取捨選択には、常にバイアスがかかっているとも言えるからです。この事実は、あらかじめご了承ください。僕は、このサイトで公開するだけの価値を認めないリソースを扱いません(ページやファイルを僕のコンピュータに保存しているかもしれませんが)。また、法的に公開しようがないリソースを無断で扱ったりもしません。
UNIX が登場した当時からシェルを使っている技術者もいると思いますが、彼らから何らかの批判なり冷笑を浴びせられるのでは?
これは大いにあります。私は、中学生の頃に SHARP の MZ-80B という8ビット・コンピュータに初めて触れてからコンピュータを使ってきましたが(途中、10年ほど OASYS という業務用ワープロのオペレータをしていて、汎用のコンピュータを全く使っていなかった時期があるため、UNIX や Linux や Mac はもちろん、たとえば Windows 95 までの Windows を使った経験はありません)、UNIX 系列の OS を使ったのは2000年代に入って FreeBSD を会社の古いノート・パソコンに入れたのが最初でした(Linux であれば、以前の職場ではウェブ・サーバを RedHat で運用していましたが)。したがって、同時代の経験としても UNIX を使ったことはありませんし、それ以降に使うようになったユーザとしても大して経験は長くありません。よって、ここで書いている個人的な理解や解釈や意見については、情報なり知識なり経験なり、あるいはシステム開発に携わる一人としての見識においても、色々と不足している点があることは事実でしょう。このため、UNIX をそれなりに使っていた人々、それから UNIX が市場に登場した頃は産まれていなかったとしても、ユーザとして運用してきた経験が僕よりも長い人々からは、色々な批評を受けることは承知しています。これは、私が大学で専攻していた科学哲学と事情は同じですし、プロとして開発に携わっているウェブ・アプリケーションの開発においても(この場合は、実際に電通やトップ・クライアント企業の人々がソース・コードを読んでどうこうと批評するわけではありませんが)、結果に関しては同じ責任を負っています。
ということなので、もちろん当サイトのコンテンツについては誰かれの区別なくご意見や批評は歓迎します。ただし、一点を除いて。その一点とは、「こんなコンテンツは誰でも作れる」とか「俺ならもっと良いものが作れる」といった類のものです。お願いですから、そうであれば、あなたが私の代わりに良いコンテンツを作って公開してください。これはオープン・ソースのコミュニティで守られている気風と同じです。コンテンツについての批評は構いませんが、サイト全体を指して無意味と断ずるのであれば、あなたがそれに代わる何かを公開する責任があります。実際にお金を使ってサーバやドメインを維持していて、更には哲学者として生きるという本分をもっている人間が人生の残り少ない時間の一部を使っているわけですから、それを凌駕する実績を出せない限り、そういう批評は Twitter で他人の成果をクズみたいな日本語文字列で気軽に断罪している子供(そして、子供にも劣るような知性の高齢者も含む)と同じです。
したがって、内容については批判や評論や質問はかまいませんが、できもしないことを言う人間には「なら、お前がやりさらせ」としか言いようがありません。私は、いわゆる「オタク」と呼ばれている人々が、自分の知っていたりアクセスできる範囲のディテールに固執して得られる情報の《量》にこだわるだけで、あたかも学者や専門家の真似事ができるかのような錯覚に陥っているコンプレックス丸出しの集団、あるいは関連するコミュニティのヘゲモニーを詰まらない蘊蓄の積み上げで掌握できるかのように夢想する、《筋の悪いマニア》であることを正しく見抜いている人間です。どれほど UNIX を使ってきたのであれ、本質的に自分自身の得た知識や経験の使い方や意義を正しく理解しない人は、どれほどの年季が入っていようと、私からすれば経験が《長いだけ》の凡庸なシステム開発者にすぎません。私は、残念ながら凡人から学ぶ必要はないというアイデアにコミットしている哲学者なので(もちろん学ぶべきことがある人もいるとは思いますが、《それが誰なのかを調べる》コストをかける仕事は哲学者の本分ではありません。社会学者や STS の研究者との分業として、彼らに期待しています)、「俺って、UNIX を1980年から使ってるし」とか言われても、知ったことではありません。私に何かを学ばせたり反省させたいのであれば、私があなたから学ぶべきだと思えるような、あなたの有能さを証明してください。もちろん、「東大教授」とか「{ITゼネコンの社名}どこそこ研究所長」といった些末な肩書は哲学者には通用しないということをお忘れなく。

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook