macroscope

( はてなダイアリーから移動しました)

Unix のコマンド名 -- 不満だが がまんしてつかう

【まだ書きかえます。いつどこを書きかえたかを必ずしも明示しません。】

- 1 -
[2022-04-25 Unix系 OS (例、Linux) のいいところ、不満だががまんするところ] のなかで、つぎのように書いた。

古くからあるコマンドは、字数がすくなく、1文字まちがえると他の有効なコマンドになって予想外の動作をしてしまうことが多い。また、すなおに連想される語ではなく (たとえば cat は猫でも catalog でもない)、いちいちおぼえなければならないことが多い。

そのなかみについて、もうすこし書いてみる。ただし、客観的な評価ではなく、わたしの主観的な感想がおもになる。

- 2 -
「ls」が「list」の略であることは、いわれればすぐおぼえられる。

しかし、何のリストであるのかがあきらかでない。ほかの OS では「list」が ファイルの内容を表示するコマンドであることがあったと思う (どの OS でそうだったか、おもいだせなくなってしまったが)。原始的な OS をかねていたパソコン内蔵の Microsoft Basic で「list」が主メモリーに読みこまれていたBasicプログラムの内容を表示するコマンドだったことはたしかだ。

ls がファイル名を表示するものであり、とくに指定しなければ現在作業中のディレクトリのファイルの一覧を表示するものであることは、そういうものとしておぼえるしかない。

- 3 -
Unix でファイルの内容を表示するコマンドは cat だといわれていた。

cat といわれて、なにをするコマンドなのかは直観的にわからない。ここに猫がでてくる可能性はひくいとおもう。しかし、1970年代すでに、計算機をつかう目的のひとつに文献目録があげられていて、catalog がよく話題になり、略語のなかで cat が catalog をしめすことはよくあった。cat が catalog でないと知って、わたしはあてがはずれたのだった。

Unix の cat は concatenate の略だとされている。わたしはその話をきくまで知らなかった英語の単語だが、「連結する」のような意味だ。concatenate はコマンド名としてはいかにも長いから、略したくなるのはわかる。しかし cat から concatenate は連想しにくい。「連結する」ならば join でよいのではないかとおもったりもするが、join は数学では集合演算としての意味をもつから、ファイルの内容を単純につなぐのには不適切なのかもしれない。

それにしても、複数のファイルの内容を連結して標準出力に書きだすのが主目的であるコマンドをもってきて、1個のファイルの内容を標準出力に書きだすのはその特殊なばあいにすぎない、というのは、いわれてみればもっともではあるものの、「0も 整数である」ことのたぐいの数学の観念が直観のレベルまでしみついた人でないと、納得しにくいとおもう。

実際には、1980年ごろ、Unixユーザーがテキストファイルの内容を画面でみるときにすすめられたコマンドは more だった。このプログラムは、端末の画面がいっぱいになる行数まで表示すると「more」という文字列をだす。「まだ あります」というわけだ。ユーザーの応答をまって、つぎの1画面ぶんを表示する。cat でファイルの内容を表示させて、はじめのほうがながれていってしまった経験をした人ならば「more」のありがたさはわかる。しかし、cat をじゅうぶん経験していない人にとって、「ファイルの内容を表示させる代表的なコマンドの名まえが more である」というのはわかりにくい。

さらに、(Unix標準のコマンドセットにはふくまれなかったとおもうが) less というのがでてきた。more は ファイルのなかを前進するだけで、うしろにもどることができないが、less は もどることができる。more を知っていれば、「逆むきも可能な more」をさして less というのはもっともだ。しかし「ファイルの内容を表示させる代表的なコマンドの名まえが less である」というのはわかりにくい。しかも、どのコマンドをつかうか口頭でつたえたいとき、less と ls とはまぎらわしい。

- 4 -
mv が move の略であるのはわかりやすい。そして、ディレクトリーの木 (tree) 構造のなかの ある場所からほかのある場所にファイルを移動するときにその名まえのコマンドをつかうことは、直観的にわかる。

しかし、所属ディレクトリをかえずにファイル名をつけかえたいときにも mv をつかうのは、わかりにくい。

ほかの OS でファイル名をつけかえるコマンドが rename だったことをわたしはおぼえている。ただしこれもどの OS だったか記憶がたしかでなくなった。

rename の機能を mv ですませることにしてしまったのも、一般の機能のコマンドがあればその特殊なばあいのためのコマンドはいらないという発想で、わたしからみると数学者的なものに感じられる。

- 5 -
rm は remove の略である。remove ということばの日常の英語での意味がわかっていれば、これをファイルやディレクトリをけすコマンドの名まえにすることは直観的にわるくないだろう。

しかし、rm と mv は文字数も同じであり、同じ字をふくむ。しかも語源も関連している。まぎらわしすぎないだろうか。

わたしが学生のころ (1970年代末)、どこかの OS で最初に知った「ファイルをけす」コマンドの名まえは erase だった。わたしはそれを英語の単語として中学生のときから知っていた。消しゴムも、黒板ふきも、eraser だ、ということをおしえられていたからだ。つぎに知ったコマンド名は delete だった。これはわたしがそれまで知らないことばだったが、計算機上でファイルをけしたり、そのエディタの中で行をけしたりする機能でしょっちゅうつかったから (省略形「del」でつかうことがおおかったが)、そういうものとしておぼえてしまった。

大学院生のころ (1980年代の前半)、Unix にふれることになった。UC Berkeley でつくられた、当時 BSD Unix とよばれていたものだった。そこには、自習する人のための、いわゆる computer-aided learning のソフトウェアである learn というものがあった。「人工知能」といわれていたかもしれないが、いま人工知能といわれる「機械学習」のたぐいではなく、おそらく決定論的な状態遷移がくみこまれていたのだとおもう。

learn の最初のいくつかのステップはうまくいった。そこで、「ファイル a のなまえを b とつけかえなさい」のような問題が出た。期待されるこたえは「mv a b」だった。learn は、そこでユーザーが「mv b a」とか「cp a b」とかやってしまうことへの対応はできたにちがいない。ところがわたしは「rm a b」とやってしまった。コマンド名がうろおぼえで、あたまのなかでrename と「re- move」とがまざってしまったのだ。learn はユーザーがうちこんだコマンドを実行してしまう。そして、Unix は存在しないファイルをけせと言ってももんくをいわない。結果として、ファイル a も b も存在しない状態になった。それは learn がそのステップで予期していなかった状態だったらしい。そこからわたしは、なにをやっても つぎに すすめなくなった。

かりにも大学の学士課程をすでに卒業していたわたしが、英語の「remove」をおぼえておらず「re- move」と分解して考えるレベルだったのがいけないのだとはおもう。しかしいくらかは、Unix が rm というコマンド名をえらんだのがまずい、とも おもっている。

- 6 -
こちらは Unix のコマンド名の問題というよりも日本語などの自然言語 (人間の言語) の問題なのだが . . . .

(Unix ではディレクトリもファイルだから) mv は ディレクトリを移動することができる。ところが、cd もディレクトリを移動するコマンドだといわれる。「ディレクトリを移動する」ということばは おなじだが、計算機上でおこることはまったくちがう。

mv の対象となるディレクトリは、ディレクトリの木を構成する要素だ。ひとつのディレクトリを、木のうちの ある場所から別の場所に移動することによって、ディレクトリの木の構造がかわる。

cd の対象となるディレクトリは、現在作業中のディレクトリだ。cd はディレクトリの木の構造をかえない。cd によって、作業者が (といういいかたをしておこう)、ディレクトリの木のなかの ある場所から別の場所に移動するのだ。

「ディレクトリを移動する」という表現は、mv をさしてつかうべきだろう。 cd については「作業ディレクトリを変更する」 「current directory を変更する」のようにいうのがよいのだろう。