200405-13.md

Truth of the Legend -- UNIX 考古学 第１３回

2BSDのex/vi

リード文

前回はBSD Unixのルーツである2BSDを動かしてみましたが、 今回は引き続き2BSD上でex/viコマンドをビルドし、利用してみます。 termcapの登場、シェルスクリプトの解釈など興味深い話題もありますが、 オリジナルのviコマンドを利用してみると、意外な事実に気が付きます。

---

Ancient Unixのソースを読む

この連載も今回で１３回目を迎えます。そう、２年目に突入しました。 風変わりなカルトネタ満載のこの連載が１年も続いたのには、 まずは読者の皆さんの御理解、それに毎月月末になると必ず発生する 厄介ごとに付き合ってくれる編集部やその他の諸氏の協力の賜です。 この場を借りて感謝したいと思います。で、この連載、既に１２回を 過ぎたのに内容的には当初予定の半ばぐらいをまだウロウロしてます。 そう、連載はまだ続きます。

こういう状態になってしまった、つまり御紹介したい内容が当初の見積りよりも 多くなってしまった大きな理由の１つは、Ancient Unix を利用した実習的解説を 試みているからでしょう。確かに、このような古惚けた Unix を動かす 試みにどのような価値があるかは議論の分かれるところです。 もし「連載で何故、実習的解説を行うのか？」と尋ねられたとしたら、 私の個人的な正直な回答は「そこにソースがあるからだ！」です。 私の本音はともかくとして、もう少し一般に配慮した答を述べるとすれば、 やはり「教育的価値を見出すことができる」という理由に尽きると思います。

今日、コンピュータに関わる技術は一定のレベルでの成熟を迎えている ように思います。故に今日では「新しい技術を開発する」ことよりも、 「既存の技術をどのように活用していく」ことに重点が置かれる ようになってきました。それだけ既存の技術蓄積が膨大なものになったと 言えるでしょう。この状況はこれからコンピュータを始めようとしている 若い方々にとって、非常に負担の大きな状況なのではないかと私は思います。 なぜなら、「既存の技術」を手っ取り早く理解することが求められるからです。 必然的に「既存の技術」をブラックボックスとして取り扱わざる得なくなります。 実際、無数のブラックボックスを積み上げられて、それらを組み合わせて 何か役に立つものを求められるというのは、そのための特別な才能を 持ち合わせている方を除けば、大変辛い仕事なのではないでしょうか？

かといって「既存の技術」の中身を理解するというのも今日では大変な仕事です。 例えば、Linux カーネルというのは多くの技術者にとって 関心の高い「既存の技術」ですが、その中身を全て理解するというのは、 それこそ途方もない試みのような気がします。何故なら既に Linux カーネルは それ自体が非常に大きなソフトウェアになっていますし、 更に今もってコードは膨張し続けているからです。 こういったシステムを対象に「中身を全て理解する」こと自体が 終りのない作業になりかねない。

そこで「実際に使われている技術と等価だが、もっとシンプルで、 もう改変されることのないもの」という存在として Ancient Unix は 価値があるのではないかと私は考えています。例えばパイプを理解するのに 必ず Linux カーネルを読まなければならない必要はないはずです。 もっともリソースの小さいハードウェアで動いていた Ancient Unix の パイプの実装の方がもっとシンプルで小さい (故に理解し易い) ものだと 思います。私が主張する Ancient Unix の「教育的価値」とは こういったものなのですがね。

こういう意図の元に、私は Ancient Unix を実際に使うための方法、 すなわち実習的解説を試みているわけですが、とはいえ現実に Ancient Unix、 例えば Version 7 Unix でプログラムを書くのは骨が折れますよね？ そのもっとも大きな原因の「使い慣れたエディタが動かない」ってこと じゃないでしょうか？ 確かに ed コマンドでソースを修正するのは 私でも疲れます、本当に。そこで今回は Version 7 Unix に 2BSD の ex/vi を インストールする方法を御紹介することにします。vi は現在でも主要なエディタの １つですので、これで Version 7 Unix (2BSD) の上での作業も効率が 格段に改善される方も多いでしょう。

「emacs はどうなんですか？」と仰る方もいるでしょうが、、、しばらく お待ちください。連載は続きます。

ex/vi のビルド

ex エディタとその visual mode (すなわち vi) の起源については、 既に第１１回の 1BSD の御紹介の際に説明しましたので、 ここで繰り返す必要はないでしょう。

1BSD では Version 1.1 であった ex も、2BSD では Version 2.0 に メジャーアップデートされています。この２つのディストリビューションは 付属するドキュメントに時期が明確に書かれていないため、いつ頃配布される ようになったか正確な時期がわかりませんが、おそらく半年から１年弱の 期間しか空いていなかったと推測されます。その期間内でメジャーアップデートが されるということは、ex/vi は正しくこの時期に開発中のソフトウェアだったと いうことでしょう。

第１１回では ex/vi は Ken Thompson の ed や George Coulouris の em (Editor for Mortals) を「拡張した」ソフトウェアといったニューアンスで 説明したかと思いますが、実際には ed や em がユーティリティクラスの 比較的コンパクトなプログラムであったのに対し、ex/vi はサブシステム クラスの (当時としては) 巨大なソフトウェアでした。このヒューマン インターフェースを重視し、そのために多くを作り込む姿勢は、同じ時期に XEROX の Palo Alto 研究所で誕生し、1980 年代以降隆盛を極めている ウィンドシステムの事例などからもわかるように、1970 年代後期の トレンドだったと言えるでしょう。故に ex/vi のコンパイルでは そのデカさが問題になることが多かったようです。今回紹介する手順でも そのデカさをかいま見るところがありますので注意してください。

それでは ex/vi のビルドを始めましょう。 今回、付属の CD-ROM に収録したソースコードは、 前回と全く同様のものです。が、以降で紹介する手順は 前回御紹介した作業を全て終えていると仮定して説明していきます。 その詳細については前回の記事を確認してください。

ex をコンパイルする前に

ex をコンパイルする前に、まず、前回インストールした 2BSD コマンドに手直しが必要なところが２箇所あります。

シェルスクリプトの修正

その１つはシェルスクリプトの関する修正です。実行例１を御覧ください。

実行例１ /usr/ucb にインストールされるシェルスクリプトの修正

$ pdp11

PDP-11 simulator V3.0-2
sim> set cpu URH70
sim> set cpu 2M
Disabling XQ
sim> set rp0 RP06
sim> att rp0 rp0.dsk
sim> set rp1 RP06
sim> att rp1 rp1.dsk
sim> boot rp0
boot
Boot
: hp(0,0)unix
mem = 2020544
# DATE 200403101722
WED MAR 10 17:22:00 JST 2004	←  日付の設定を忘れないように
# RESTRICTED RIGHTS: USE, DUPLICATION, OR DISCLOSURE
IS SUBJECT TO RESTRICTIONS STATED IN YOUR CONTRACT WITH
WESTERN ELECTRIC COMPANY, INC.
WED MAR 10 17:22:02 JST 2004

login: root
Password:
You have mail.
# /etc/mount /dev/rp7 /mnt	←  2BSD のソースがあるファイルシステムを
# cd /mnt/src			    マウントする
# ls *.sh
astags.sh
ctags.sh
cxref.sh
makewhatis.sh
print.sh
w.sh
#
# cp astags.sh astags.sh.orig
# ed astags.sh

    ....

# diff -e astags.sh.orig astags.sh
1,2d
#
# cp ctags.sh ctags.sh.orig
# ed ctags.sh

    ....

# diff -e ctags.sh.orig ctags.sh
1,2d
#
# cp cxref.sh cxref.sh.orig
# ed cxref.sh

    ....

# diff -e cxref.sh.orig cxref.sh
1,2d
#
# cp makewhatis.sh makewhatis.sh.orig
# ed makewa#hatis.sh

    ....

# diff -e makewhatis.sh.orig makewhatis.sh
1,2d
#
# cp print.sh print.sh.orig
# ed print.sh

    ....

# diff -e print.sh.orig print.sh
1,2d
#
# cp w.sh w.sh.orig
# ed w.sh

    ....

# diff -e w.sh.orig w.sh
1,2d
#
# cp astags.sh /usr/ucb/astags
# cp ctags.sh /usr/ucb/ctags
# cp cxref.sh /usr/ucb/cxref
# cp makewhatis.sh /usr/ucb/makewhatis
# cp print.sh /usr/ucb/print
# cp w.sh /usr/ucb/w
#

2BSD で /usr/ucb にインストールされるコマンドには６つのシェル スクリプトが含まれますが、前回の状態ではエラーが発生して実行できません。 その理由は、これらのシェルスクリプトはいずれもコメント行から始まるのですが、 Version 7 の /bin/sh はこの先頭のコメント行を認識せず、 エラーになってしまいます。(★コラム１参照) このため ex をコンパイルする際に /usr/ucb/ctags を使用している ところで make が異常終了します。 本来、Bourne Shell を手直しするべきなのでしょうが、 ここは手っ取り早くシェルスクリプトの先頭のコメント行 ２行を削除することで対処しました。

C Shellのリビルド

もう１つの手直しすべきところは C Shell についてです。 前回の手順では C Shell を Version 6 Unix に合わせてコンパイルしましたが、 このコンフィグレーションだと setenv コマンドが使えません。 今回、ex を動作させるために環境変数 TERM の設定をする必要があるのですが、 Bourne Shell の環境変数の設定は煩わしいので(★コラム２参照)、 C Shell の setenv コマンドを使いたいところです。 そこで setenv コマンドを使えるように C Shell を再コンパイルします。 実行例２を御覧ください。

実行例２ C Shell で setenv コマンドを使えるようにする

# cd /mnt/src/csh
# make clean
rm -f a.out strings x.c xs.c
rm -f *.o
# cp sh.init.c sh.init.c.orig
# ed sh.init.c

    ....

# diff -e sh.init.c.orig sh.init.c
86d
84d
# cp sh.func.c sh.func.c.orig
# ed sh.func.c

    ....

# diff -e  sh.func.c.orig sh.func.c
766d
711d
#
# make install

    ....

cc -n sh.o sh.dol.o sh.err.o sh.exec.o sh.exp.o sh.func.o sh.glob.o sh.hist.o  sh.lex.o sh.misc.o sh.parse.o sh.print.o sh.sem.o sh.set.o  sh.wait.o alloc.o sh.init.o 11printf.o getpwent.o getpwnam.o   getpwuid.o errlst.o strings.o
cp a.out x
strip x
rm -f /bin/csh
mv x /bin/csh
rm -f /bin/makesh
ln /bin/csh /bin/makesh
#
# /bin/csh
# set path=($path /usr/ucb)
# set
argv    ()
home    /
path    (/etc /bin /usr/bin /usr/ucb)
prompt  #
shell   /bin/csh
status  0
# printenv
HOME=/
PATH=:/bin:/usr/bin
# setenv TERM vt100
# printenv
HOME=/
PATH=:/bin:/usr/bin
TERM=vt100
# exit
# #

オリジナルのソースでは setenv コマンドに 関連する機能は sh.init.c および sh.func.c に実装されており、 マクロ V6 が定義されてない時だけコンパイルされるようになっています。 そこで関連する #ifndef と #endif を削除しています。

必要な修正が csh をコンパイル／インストールしてください。 インストール後は setenv コマンドが使えることを確認しておきましょう。 この例では環境変数 TERM に端末名 vt100 を設定しています。

ちなみに、この修正は必須ではありません。C Shell のソースコードを 汚したくない方は、C Shell ではなく Bourne Shell で環境変数の 設定をしてもらっても構いません。余談ですが Version 7 Unix では ライブラリ関数 setenv() は存在しません。詳細を★コラム３で 説明してますので、気になる方は参考にしてください。

ex のコンパイル／インストール

それでは ex のコンパイル／インストールにかかります。 /mnt/src/ex/READ_ME を見ると、冒頭に次のような２行があります。

There are 2 skeletal makefiles: makefile.v6 which I made from
the local makefile.CORY, and makefile.v7 which I made from makefile.VAX.

これを見ると「makefile.v7 は VAX 用なので、 makefile.v6 を使った方が良いのかな？」という 気持ちになっちゃうのですが、さにあらず。私が試みたところでは csh の時とは違って、ex の場合は makefile.v7 を修正して使うのが 正解のようです。

ex をコンパイルする上での問題点としては２つあります。 １つは C Shell と共通の問題で printf の内部下位関数 _strout() の 引数の並びが Version 7 Unix と UNIX/32V で異なること。つまり、 C Shell と同様に ex でも自前の printf を使っているってことですね。 これの対処法も同じで printf.c の代わりに 11printf.c を使います。 もう１つの問題は ex_io.c です。この C ソースは大き過ぎるため、 コンパイル時にエラー "Symbol table overflow" が発生します。 このエラーはコンパイラの問題なので、本来はコンパイラの方を 手直しするべきなのですが(★コラム４、★コラム５参照) 、 コンパイラを修正するのは大変危険なので「ex_io.c を半分にぶった切る」 という荒技で乗り切ることにしました。実行例３を御覧ください。

実行例３ ex のコンパイル／インストール

# cd /mnt/src/ex
# cp makefile makefile.v7
# diff -e makefile.v7 makefile
58,61c
        ${CC} -c xs.c
        mv xs.o strings.o
.
43c
        11printf.o strings.o
.
40c
        ex_io0.o ex_io1.o ex_put.o ex_re.o ex_set.o ex_subr.o ex_temp.o ex_tty.o \
.
# cp ex_io.c ex_io0.c
# ed ex_io0.c

    ....

# diff -e ex_io.c ex_io0.c
501,1000d
20,24d
# cp ex_io.c ex_io1.c
# ed ex_io1.c

    ....

# diff -e ex_io.c ex_io1.c
24,501d
16,19d
#
# make
/usr/ucb/mkstr - ex2.0strings x ex.c
cc -E -O -DTABS=8 -DLISP -DCHDIR -DUCVISUAL xex.c | /usr/ucb/xstr -c -
rm -f xex.c
cc -O -DTABS=8 -DLISP -DCHDIR -DUCVISUAL -c x.c
mv x.o ex.o

    ....

# make install
/usr/ucb/ctags ex.c ex_*.c
cc -i ex.o ex_addr.o ex_cmds.o ex_cmds2.o ex_cmdsub.o ex_data.o ex_get.o  ex_io0.o ex_io1.o ex_put.o ex_re.o ex_set.o ex_subr.o ex_temp.o ex_tty.o  ex_v.o ex_vadj.o ex_vget.o ex_vmain.o ex_voperate.o  ex_vops.o ex_vops2.o ex_vops3.o ex_vput.o ex_vwind.o  11printf.o strings.o -ltermlib
chmod 711 /usr/ucb/ex
/usr/ucb/ex </dev/null
rm /usr/ucb/ex /usr/ucb/e /usr/bin/ex /usr/ucb/edit /usr/ucb/vi
rm: /usr/bin/ex nonexistent
rm: /usr/ucb/vi nonexistent
*** Error code 2 (ignored)
cp a.out /usr/ucb/ex
cp ex2.0strings /usr/lib/ex2.0strings
cp ex2.0strings /lib/ex2.0strings
ln /usr/ucb/ex /usr/ucb/edit
ln /usr/ucb/ex /usr/ucb/e
ln /usr/ucb/ex /usr/bin/ex
ln /usr/ucb/ex /usr/ucb/vi
chmod 1711 /usr/ucb/ex
#

まず、デフォルトの makefile は Version 7 Unix (UNIX/32V) 用なので、 makefile.v7 にコピーを残して makefile の方を修正します。 修正点は３箇所。前述の問題に対応した２箇所と strings.o を作成する ところで VAX 用の修正が入っているため、これを削除しました。 続いて ex_io.c をぶった切って ex_io0.c と ex_io1.c を作成します。 好都合なことに単純な行削除だけで、奇麗に２つに分けることができました。

そして make と make install を行います。注意して欲しいのは make install を実行する前にディレクトリ /usr/bin を作成することです。 makefile は /usr/ucb に ex をインストールすると同時に /usr/bin にも ex のリンクを張ります。ディレクトリ /usr/bin がないと make install は 途中で異常終了しますので、予めディレクトリを作っておいてください。

以上で ex/vi のコンパイル／インストールは終りです。

画面表示を決めるtermcap

ex 2.0 の特徴といえば、端末データベースとして termcap が 初めて使われるようになったことが上げられます。今日、 termcap と言えば、ウィンドウシステムのターミナル エミュレータを使う時ぐらいしかお世話になりませんので、 若い皆さんにはあまり馴染みがないかも知れません。が、 私のようなオールドユーザーにとって、termcap といえば Unix の 悪夢の１つに上げられるほど「厄介」との印象が強いでしょう。 昔は妙なターミナルが多かったですからねぇ。

ex の初出は 1BSD でしたが、その時には termcap の前身である ttycap が使われていました。リスト１を見てもらうとわかるように なんだかパスワードファイル (/etc/passwd) みたいな印象ですね。 この ttycap を更に改良したのが皆さんが良くご存知の termcap で、 サポートされたのは 2BSD からです。

リスト１ ttycap

l1|11/10:0:0:?
ca|adm3a|3a:0177440:0000332:li#24:co#80:cl=^z:ho=\036:nd=^l:up=^k:am:bs:ca
cl|adm3:0177440:0000332:li#24:co#80:cl=^z:am:bs
td|decwriter|dw2:0177444:0000332:co#132:bs:os:am
pd|dtc300s|diablo|dtc:0137446:0000330:if=/usr/lib/tset.dtc_tabs:co#132:\
hu=\EH:hd=\Eh:up=^z:bs:it:os:pt:pl du|dialup:0:0:
pg|gsi:0137446:0000330:is#1:co#132:hu=\EH:hd=\Eh:up=^z:bs:it:os:pt:pl
g0|gt40:0177444:0000332:li#30:co#72:bs:os
g2|gt42:0177444:0000332:li#40:co#72:bs:os
ch|hazeltine2000:0177440:0000332:bs:ca
lh|hp21mx:0:0:?
cH|hp2645|2645:0177440:0000332:li#24:co#80:cl=\E&a00c00Y\EJ:ho?:nd=\EC:up=\EA:\
am:bs:ca:it:ce=\Ek\ pt:al=\EL:dl=\EM:ce=\EK:cd=\EJ
gk|tek4014:0177444:0040332:co#120:li#56:bs:os:cl=\E^l:is=\E\:
ct|teleray:0177440:0000332:co#80:li#24:cl=^l:bs
ti|ti700|ti|ti733:0151440:0020332:co#80:bs:os
t3|teletype|tty|33|35:0157440:0020336:co#72
t7|tty37|37:0:0:bs:os:hu?:hd?:up?
un|unknown|u:0:0:

2BSD に収録されている termcap のサンプルに登録されている エントリ数 (サポートしている端末数) はたった 48 種類です。 オールドユーザーの私がその中に書かれている個々の端末名を見ても 「全く知らない」あるいは「名前は聞いたことがある」ものばかりです。 必然的に私たちの環境に合わせて新しいエントリを記述する必要があります。

termcap のエントリを追加する

読者の多くの方々は X Window System が動作する Unix 環境を お使いでしょうから、今回は xterm や kterm あるいは デスクトップ環境の標準ターミナルエミュレータを想定して解説します。

2BSD の termcap は現在のものと基本的に変わりません。 しかし★表１を見てもらうとわかるように、 定義されていた capabilities の数は４４個と 現在のものとは比べものにならないほど少ないものでした。 (ちなみに、現在の termcap の man page で capability の数を数えてみたところ 274 もありました。 2BSD の termcap は文字通り ex/vi をサポートするだけのための 機能しかなかったようです)

表１ 2BSD termcap の capabilities (man page より抜粋)

Name	Type	Pad?	Description
al	str	(P*)	Add new blank line
am	bool		Terminal has automatic margins
bc	str		Back cursor if not `^H'
bs	bool		Terminal can backspace with `^H'
cd	str	(P*)	Clear to end of display
ce	str	(P)	Clear to end of line
cl	str	(P*)	Clear screen
cm	str	(P)	Cursor motion
co	num		Number of columns in a line
da	bool		Display may be retained above
db	bool		Display may be retained below
dc	str	(P*)	Delete character
dl	str	(P*)	Delete line
dm	str		Delete mode (enter)
ed	str		End delete mode
ei	str		End insert mode; give ``:ei=:'' if `ic'
eo	str		Can erase overstrikes with a blank
ho	str		Home cursor (if no `cm')
hz	str		Hazeltine; can't print ~'s
ic	str	(P)	Insert character
if	-		Name of file containing `is'
im	bool		Insert mode (enter); give ``:im=:'' if `ic'
in	bool		Insert mode distinguishes nulls on display
ip	str	(P*)	Insert pad after character inserted
is	str		Terminal initialization string
li	num		Number of lines on CRT screen
ll	str		Last line, first column (if no `cm')
ma	str		Control character map for arrow keys
mi	bool		Safe to move while in insert mode
nc	bool		No correctly working carriage return (DM2500)
nd	str		Non-destructive space (cursor right)
os	bool		Terminal overstrikes
pc	str		Pad character (rather than null)
se	str		End stand out mode
sf	str	(P)	Scroll forwards
so	str		Begin stand out mode
sr	str	(P)	Scroll reverse (backwards)
ta	str	(P)	Tab (other than `^I' or with padding)
ul	bool		Terminal underlines even though it doesn't overstrike
up	str		Upline (cursor up)
vb	str		Visible bell (may not move cursor)
ve	str		Sequence to end open/visual mode
vs	str		Sequence to start open/visual mode
xn	str		A newline is ignored after a wrap (Concept)

termcap の capabilities は原則として上位互換になっていますので、 現在一般に使われている termcap の妥当なエントリから 2BSD termcap の capabilities だけを拾い集めると必要なエントリの情報が作成できます。 今使ってらっしゃる Unix の /etc/termcap から xterm あるいは kterm の エントリを見つければよいのですが、「ファイルが当てにならない」 あるいは「Windows で作業している」のであれば、 Termcap/Terminfo Resources Page から termcap ファイルを取ってくると良いでしょう。 念のため、私の作成した termcap への追加エントリを リスト２に掲載しておきます。

リスト２ termcap の追加エントリ

x0|xterm|:\
	:co#80:li#24:am:bs:mi:xn:\
	:al=\E[L:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:\
	:dc=\E[P:dl=\E[M:ei=\E[4l:ho=\E[H:im=\E[4h:\
	:is=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>:\
	:nd=\E[C:se=\E[m:sf=^J:so=\E[7m:sr=\EM:ta=^I:up=\E[A:

実際のエントリの追加作業は ed を使って /etc/termcap を直接修正します。 (実行例４)「これで ed を使うのも最後」と思えば多少長い行入力も 苦にならないでしょう :-p

実行例４ termcap へのエントリの追加

# cd /etc
# cp termcap termcap.orig
# ed termcap

    ....

# diff -e termcap.orig termcap
0a
x0|xterm|:\
        :co#80:li#24:am:bs:mi:xn:\
        :al=\E[L:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:\
        :dc=\E[P:dl=\E[M:ei=\E[4l:ho=\E[H:im=\E[4h:\
        :is=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>:\
        :nd=\E[C:se=\E[m:sf=^J:so=\E[7m:sr=\EM:ta=^I:up=\E[A:
.
#

ちなみに xterm はミニコンのターミナルの代名詞であった VT100 (厳密には VT102) をエミュレートするターミナルエミュレータです。 ★コラム６で VT100 について紹介しておきましたので、参考にしてください。

ex/vi の起動

さて、これで準備は全て整いました。試しに ex/vi を起動してみましょう。 Unix と SIMH を一旦止めて、xterm (kterm やその他の互換ターミナル エミュレータでも構いませんが) から再起動します。ここで注意して 欲しいのは、起動するターミナルエミュレータのウィンドウサイズを 80 文字× 24 文字にするということです。

というのも、この当時の ex/vi は表示対象としてターミナルしか 想定していません。先に紹介した termcap のエントリ例では表示画面が 80 文字× 24 文字 であることを仮定していますし、実行中にその大きさが 変わっても、それを認識して表示の大きさを調整するようなことはできません。 xterm は特別の設定をしていなければ、デフォルトで表示画面を 80 文字× 24 文字 に設定して起動します。以降の操作でも ウィンドウサイズを変えないように注意してください。

xterm のウィンドウが開いたら、SIMH を立ち上げ Unix を再起動します。 (実行例５)

実行例５ ex/vi を起動してみる

$ pdp11

PDP-11 simulator V3.0-2
sim> set cpu URH70
sim> set cpu 2M
Disabling XQ
sim> set rp0 RP06
sim> att rp0 rp0.dsk
sim> set rp1 RP06
sim> att rp1 rp1.dsk
sim> boot rp0
boot
Boot
: hp(0,0)unix
mem = 2020544
# DATE 200403141245
SUN MAR 14 12:45:00 JST 2004
# <CNTL-D>
RESTRICTED RIGHTS: USE, DUPLICATION, OR DISCLOSURE
IS SUBJECT TO RESTRICTIONS STATED IN YOUR CONTRACT WITH
WESTERN ELECTRIC COMPANY, INC.
SUN MAR 14 12:45:16 JST 2004

login: root
Password:
You have mail.
#
# TERM=xterm
# export TERM
# PATH=$PATH:/usr/ucb
# export PATH
# printenv
HOME=/
PATH=:/bin:/usr/bin:/usr/ucb
TERM=xterm
#
# stty 9600
# tset
Erase set to control-H
#
# /etc/mount /dev/rp7 /mnt
# cd /mnt
#
# vi READ_ME

    ....

#

システムが起動したら取り敢えず root でログインをしてください。 ex/vi を起動するためには少し設定が必要です。まず環境変数 TERM に termcap のエントリ名 xterm を設定します。ついでに環境変数 PATH に /usr/ucb も追加して BSD コマンドが使えるようにしておきましょう。 環境変数の設定が終ったら printenv で設定内容の確認をします。 次に端末の設定を行います。まず回線速度の設定です。今回は SIMH の上で 動かしていますので、この設定は本質的に意味がないと思われるでしょうが、 実は ex/vi は回線速度をチェックして、1200 baud 以下の場合には 画面のした半分しか使わないようになります。そこで、ここでは 1200 より 大きな値を設定しておきましょう。次に tset コマンドを実行します。 この BSD コマンドは termcap のエントリを参照して、 その他の必要な回線設定をしてくれます。"Erase set to control-H" と 表示されていますが、これ以降１文字削除は # キーではなく CNTL-H に なります。なお、この環境変数と回線に対する設定は、当時はログイン時の 設定として csh の .login や sh の .profile などに記述されることが 一般的でした。

それではまず vi から起動してみましょうか。何か適当なファイルを 開いてみてください。皆さんよくご存知の vi ですから、その操作方法を ここで改めて説明するまでもないですよね、、、なんだかちょっとおかしい？ はい、実は 2BSD の ex/vi はカーソルを移動するコマンドのキーバインディングが 現在皆さんが良くご存知なものと違います。2BSD に付属する "Vi Quick Reference" を見ていただくとわかるのですが、カーソルの行移動の場合は CNTL-N と CNTL-P (これは emacs のキーバインディングと同じですね)、 あるいは + と - にバインドされています。そしてカーソルを１文字右に 移動するには space を使います。皆さんが良くご存知の j, k, l キーには 機能がバインドされていないので、これらのキーを押すと beep がなるはずです。 これはちょっと驚きですね。

キーバインディングを追加する

これでは使いづらいので j, k, l キーが使えるように手直しをしましょう。 そのためには ex/vi のソースを修正する必要があります。実行例６を御覧ください。

実行例６ j, k, l コマンドを追加する。

# cd /mnt/src/ex
# cp ex_voperate.c ex_voperate.c.orig
# ex ex_voperate.c
"ex_voperate.c" 834 lines, 14402 characters
:set number
:528
        case CTRL(n):
:a
   529          case 'j':
   530  .
:480
   480           */
:a
   481          case 'k':
   482  .
:397
   397           */
:a
   398          case 'l':
   399  .
:w
"ex_voperate.c" 837 lines, 14435 characters
:q
# diff -e ex_voperate.c.orig ex_voperate.c
528a
        case 'j':
.
480a
        case 'k':
.
397a
        case 'l':
.
# make clean

    ....

# make install

    ....

#

せっかくですから今回の修正には ex を使ってみましょう。ex は ed の 上位互換ですので、全く同じコマンドを受け付けてくれます。ed ではなく 敢えて ex を使う理由があるとすれば、それは例えば set number コマンドが 上げられるでしょう。set number コマンドを実行すると行表示の際、 行番号も表示してくれるようになります。diff -e の出力など 行指向のファイル編集が必要な場合、この機能は便利です。

ex_voperate.c の修正が終ったら、 実行例３と同じようにex/vi をインストールをして、 vi の動作を確かめてみましょう。ほら j, k, l キーが使えるように なりましたね。

オープンモードを使ってみる

苦労のかいあって、ようやくオリジナル ex/vi が出来上がりました。 が、読者の皆さんの中には「これってどんなありがた味があるの？」と感じている 方もいらっしゃるでしょう。確かに今日ではさまざまな vi クローンが存在しており、 どれも非常によく出来ているので、「本物のvi が使える」ということだけでは 今一つ魅力が薄いかも知れません。 ですがこのオリジナル ex/vi、ちまたの多くの vi クローンでは サポートされていないオープンモードが使えます。第１１回で御紹介した George Coulouris の em (Editor for Mortals) ゆずりのあのオープンモードです。 こればかりは「オリジナルだけ」の機能ですね :-p (「vi が動くなら 必要ないジャン」って意見もあるでしょうが)

オープンモードを使うためには、まず ex を起動します。 コマンドプロンプトの ":" が返ってきたら、 小文字の "o" と打ってください。これでオープンモードになります。 オープンモードでの現在行の編集操作は vi と同じです。また vi と 同じ要領で行移動もできますが、カーソルが上下に動くことはありません。 常にコマンド行の１行上に現在行が表示されます。オープンモードを 抜けるためには、小文字の "q" を打ってください。もとの ex に戻ります。

ex のオープンモードの特徴はターミナルの設定を必要としないことです。 例えば環境変数 TERM が設定されていない状態で vi を起動した場合、 "[Using open mode]" と表示されて、自動的にオープンモードで 立ち上がります。カーソルが画面を上下に動かないことを除けば、 基本的な操作は vi と変わらないので案外重宝します。お試しあれ。

※

以上、今回は 2BSD に収録されている ex/vi をビルドしてみました。 いかがだったでしょうか？ 実は、その操作方法のためか、 Version 7 Unix には私も大変レトロな印象を持っていたのですが、 不思議なもので vi が動き始めた途端、グッとモダンな印象に変わりました。 これならプログラムを書く気にもなってくるというものです。というわけで、 次回は 2BSD を使った実習の最後として、1BSD/2BSD 最大の目玉である Berkeley Pascal System に挑戦してみようと思います・・・「で、 emacs はどうなるんですか？」と仰っているあなた。連載はまだ続きます！！

---

★コラム１　Version 7 Unix でのスクリプトの実行

「あれ？なんで /bin/sh の問題なの？カーネルの問題じゃないの？」と 思った方もいると思いますが、、、今日のモダンな Unix では 実行パーミションが設定されている (実行可能な) スクリプトは カーネルの exec システムコールに対応するルーチンのなかで 先頭の１行を解釈して、そのスクリプトを受け付けるプログラムを 決定する実装が一般的です。実際、この機能があるので、モダンな Unix では perl などのさまざまなインタープリタのスクリプトをコマンドのように 取り扱うことができるのですが、Version 7 Unix ではこの機能は 実装されていません。したがって、実行可能なシェルスクリプトを 指定して exec システムコールを呼び出した場合、エラーが発生し エラーコード ENOEXEC (Exec format error) が返ってきます。

「じゃ、誰がスクリプトを実行しているの？」ということになりますが、 答えは /bin/sh 自身です。/bin/sh は execve システムコールを 呼び出して ENOEXEC が返ってきた場合、実行対象となるファイルを シェルスクリプトと仮定して、そのファイルを入力として実行することを 試みます。(ソースコード /usr/src/cmd/sh/service.c の 140 行目あたりを 御覧ください) 本文で指摘しているコメントの問題はこの後の subshell に longjump した後で発生しているわけですが、このように Version 7 Unix の シェルスクリプト機能は、非常に /bin/sh に依存する形で実装されていました。 今日のモダンな Unix で一般化されている前述の実装方法は、後に BSD Unix で 採用されたアプローチです。

★コラム２　Bourne Shell の環境変数の設定

/bin/sh が実際には bash であることが多い今日、 環境変数の設定が煩わしいと考える人はあまりいないでしょう。 実際

$ export TERM=vt100
$

の１行で設定ができるからです。 でもこの機能、実は bash の独自機能なんですね。 オールドユーザーの方は良くご存知だと思いますが、 オリジナルの Bourne Shell では、環境変数を設定する際、 まずシェル変数を設定して、その内容を環境変数に export するという ２段階の手順を必要としました。例えばこんな感じ。

$ TERM=vt100
$ export TERM
$

Bourne Shell の export コマンドでは変数の値を設定することはできません。 おそらくシェル変数の内容と環境変数を常時一致させることを狙って こういう仕様にしていたのだと推測されますが、その理由は定かではありません。 とはいえこの手順、頻繁にトラブルの原因になりました。 環境変数を設定したつもりがシェル変数しか設定してなかったとか、、、 C Shell のようにシェル変数と環境変数を独立して設定できる仕様の方が 合理的だと私は思うのですけども。

★コラム３　Version 7 Unix での setenv()

今日 setenv() は libc のライブラリ関数になっています。 が、Version 7 Unix の libc では getenv() は存在しますが、 setenv() は存在しません。「じゃぁ、環境変数はどうやって 設定するの？」という疑問は当然でしょう。オリジナルの Version 7 Unix では環境変数を設定しているのは /bin/login と /bin/sh の２つのプログラムだけで、各々自前で環境変数の領域 environ を直接参照して値を設定していました。つまりこの当時、 一般的な Unix プログラムは環境変数を参照するだけだったというわけです。

今日、私たちが知るライブラリ関数 setenv() の仕様は C Shell の 同名の内部関数がベースになったようです。中身は、、、C Shell の ソースを見てくださいね。sh.func.c の最後の方です。

★コラム４ Ritchie C Compiler へのパッチ

実は ex のコンパイル方法を探す過程で makefile.v6 も試してみました。 が、こちらでも "Symbol table overflow" が発生しました。 で、2BSD のディストリビューションの中にこの問題への対処方法を 記述したものがないかと探したところ /mnt/upgrade/c に overflow に 対処するパッチが存在しました。このディレクトリにある c0.h および c11.c はは /usr/src/cmd/c の下にある Ritchie C Compiler への パッチのようでした。

で、パッチを当てることを試みたのですが、、、うまくいきません。 どうやら元のソースが違うようです。つまり UCB で使われていた Ritchie C Compiler は Version 7 Unix に収録されていたものとは 異なるようです。まさかとは思ったのですが、念のため Version 6 Unix に 収録されている Ritchie C Compiler へのパッチも試みました。が、これもダメ。 で、「一体、UCB で使われていた Ritchie C Compiler って どのバージョン？」とまたもや頭を抱えることになりました。

数日ジタバタした結果、見つけた答えは、、、このパッチ、なんと Programmers Work Bench (正確にはおそらく PWB-2.0 ★コラム５参照) に 収録されていた Ritchie C Compiler に対するパッチだったようです。 全く Reject されることなくパッチはピッタリ当たりました。 そこでこのパッチを当てた後のソースを Version 7 Unix を持っていって コンパイルしようとしたのですが、、、全くコンパイルできません。 Version 7 Unix に収録されている Ritchie C Compiler と diff を 取ってみると、、、PWB は Version 6 Unix 仕様のシステムなので その上で動く Ritchie C Compiler も Version 6 Unix 仕様なんですね。 で、Version 7 Unix とは (システムコールなど) システム仕様が大きく 異なるためコンパイルできなかったというわけです。さすがに Version 7 Unix の仕様に合わせるよう改造するだけの時間も労力もなかったので、 ここでコンパイラを手直しするという方策は断念せざるえなくなりました。

★コラム５ Programmer's Workbench (PWB)

前回、Mashey Shell の紹介のところで触れた Programmer's Workbench (PWB) ですが、 予想に反して重要な役割を果たしたリリースであったことがわかってきました。 ここで、もう少し詳しく触れておきましょう。

前回でも御紹介したように、PWB は大規模ソフトウェア開発のための システムとして開発プロジェクトが始まったと説明しましたが、 実際には AT&T の Business Information Systems (BIS) プロジェクトが 抱える問題を解決することが目的だったようです。その問題とは、 当時の大型コンピュータが抱えていた非互換性の問題でした。 当時 BIS は IBM、UNIVAC(現UNISYS)、XEROX など異なるメーカーが提供する、 相互に互換性のない４種類以上のアーキテクチュアの上で動くソフトウェアを 開発する必要がありました。第１回で御紹介したように、当時のこの手の 大型コンピュータは使用した CPU 時間にチャージされる仕組みで、 実機での開発は大変お金がかかりました。更にあまりにもアーキテクチュアが 異なるため、(ソースコードなど)開発した成果を統一的に管理する手段も ありませんでした。で、この問題を解決するために Unix を活用しようというのが PWB プロジェクトの目論見だったわけです。

この PWB プロジェクトの中心人物は前回も御紹介した Rudd Canaday です。 この人は第２回、第３回で御紹介した Ken Thompson のチョークファイル システムの開発も手伝った Unix 開発のオリジナルメンバーの一人です。 1973 年 Version 3 Unix (および Version 4 Unix) が発表された頃に、 Unix システムそのものの開発から離れて、この PWB プロジェクトを始めた とのことです。

このプロジェクトの最大の特徴はその開発方針にありました。よくありがちな、 総論的見地に立って統合的なシステムとしてワークベンチを設計するアプローチ、 すなわちトップダウン型のアプローチは最初から除外され、BIS の開発要員の 抱えている具体的な問題を解決するツールを Unix の上に１つずつ実装して いくという、いわゆるボトムアップ型のアプローチを採用していました。 故に PWB/UNIX はシステムとしては Unix そのものであり、前回も御紹介した RJE や SCCS といった著名な PWB プロジェクトの成果は、後に Unix 上の ユニークなソフトウェア開発ツールとして生き残っていくことになりました。

Version 4 Unix をベースにしたオリジナルの PWB/UNIX と呼ばれるシステムは 1974 年にリリースされていますが、その後は Version 6 Unix をベースにした PWB 1.0 が 1977 年に、PWB 2.0 が 1978 年にリリースされています。Unix の 歴史という観点でもこれらのリリースは重要で、例えば★コラム４で述べた Ritchie C Compiler のアップデート版などが随時収録されていました。1977 年、 1978 年といえば第６回で御紹介したように Unix 自体は Version 7 の開発時期に 当たり、ポータビリティを達成するための開発作業に集中していた時期です。 実際、Version 6 がリリースされてから Version 7 がリリースされるまでは ３年半から４年という長い期間がありますが、PWB は結果的にこの長いリリース の空白期間を埋める役割も果たしたことになります。これは Version 7 で 収録された Unix の代表するような make や lex というツールが、 実は初出は PWB だったという事実からも確認できます。

PWB は 2.0 を最後にその後 PWB リリースは作られていないようです。 おそらく AT&T が Unix ビジネスを開始することになり、その成果が Unix の一部として取り込まれたからだと思われます。

現在、PWB は Ancient Unix の一部として無料でソースコードを 入手することができます。例によって The Unix Heritage Society の Unix Archive から入手するのが一番お手軽でしょう。ちなみに、 Unix Archive への PWB のソースの提供者の１人である Keith Bostic は UCB CSRG の最後の４人のメンバーのうちの一人です。ということは、 UCB は PWB のコードを入手していたということになりますね。 これが「何故 2BSD に PWB 2.0 の Ritchie C Compiler に対する パッチが収録されていたのか？」の答でしょう。

追記: 単行本では第６章で PWB を紹介しています。

★コラム６ VT100

私の世代では「コンピュータのターミナル」というと、 まず DEC の VT100 を思い出します。ウィンドウシステム全盛の昨今、 「ターミナル」という用語自体が死語のようになっていますが、 それでも VT100 の影響からは免れません。xterm や kterm など X Window System の上で動作するターミナルエミュレータは数々 存在しますが、これらのプログラムがエミュレートしている ターミナルというのは、実は VT100 (正確に VT102) です。 私たちは知らず知らずのうちに VT100 のお世話になっているんですね。

DEC の VT100 は 1978 年に発表されました。以降、ASCII CODE ベースの ターミナルのデファクトスタンダードとして広く認知され続けています。 1980 年代に製品化された多くのターミナル製品は VT100 互換を 唱っていましたし、パソコン上で動作するターミナルエミュレータでも VT100 の エスケープシーケンスをサポートするのは基本と理解されてきました。 VT100 がこのような大きな影響力を持ったのには、もちろん当時の ミニコン業界の覇者であった DEC の製品であったということも上げられますが、 もっとも重要な理由は他にあります。VT100 は ANSI 互換のターミナルの 最初の製品だったのです。

DEC が VT100 を発表した翌年の 1979 年、アメリカの標準化団体である ANSI は X3.64 "Additional Controls for Use with American National Standard Code for Information Interchange" を標準化しました。DEC は この標準化作業を横目で見ながら、並行して製品開発を行いましたが、 この製品が VT100 となりました。今日でも標準化作業と並行して 製品開発が行われることはありますが、当時はもっと極端な状況で 特定のメーカーが開発した製品が、最初から標準に適合している というようなことが結構ありました。 しかし当時影響力を持っていた DEC といえども、自社製品をここまで 影響力のあるデファクトスタンダードに押し上げる力はなかったでしょう。 現在の VT100 の地位を作ったのは ANSI X3.64 のおかげです。

この標準仕様は主にエラーが発生した後の復旧などについて、 仕様上の未定義などがありました。それ故 ANSI X3.64 の仕様に 基づいてターミナルを開発しても、製品として問題が残ってしまうのです。 DEC は ANSI X3.64 を遵守しつつも、問題の部分については独自の方法で 回避するようにして VT100 を開発しました。のちに、後発の ANSI 互換 ターミナルを開発しているメーカーも同様の問題にぶつかるのですが、 結局既に製品化されている VT100 を参考にして問題を回避したのでした。 こういった事情から VT100 は ANSI X3.64 のリファレンスの役割を 果たしただけではなく、独自の問題回避方法も提示した格好になり、 それをも含めた VT100 互換のターミナルが業界に定着したわけです。

ここで「後発メーカーが VT100 互換のターミナルを作って商売になったの？」 と疑問を持たれる方もいらっしゃるでしょう。実は十分に商売になったんですね。 例えば、かつて私が VAX のシステム管理者をしていた頃、開発用には３２台の ターミナルが接続されていましたが、そのうち純正の VT100 は２台だけで 残る３０台は全部 VT100 互換の他社製品が接続されていました。 それぐらい VT100 は値段の高いターミナルだったんですね。

後に DEC も VT100 の廉価版を製品化します。VT100 ではオプション扱いに なっていたプリンターポート(画面のハードコピーを取るために使います)を 標準装備にして少し値段を下げた VT102 と、これらのオプションを 全部削ってグッと値段を下げた VT101 の２種類が製品化されました。 xterm などはこの VT102 で追加された一部のエスケープシーケンスも サポートしているため「VT102 互換のターミナルエミュレータ」と 呼ばれています。

なお VT100 に関する技術情報を調べるためには VT100.net というホームページが便利です。DEC が発行した 技術資料もきれいに整備されて掲載されていますので、 一度御覧になってはいかがでしょうか。