ネットスラングLOL表現の変遷

どうもインターネット上を眺めていると、ネットスラングLOL表現について自分の育った環境下が全体であるように理解している人が多く見受けられ、そもそも知らない人が増えているようなので、ここで一旦まとめておきたいと思う。

なお、これらは私の手元にある集積的データベースにおいて確認されている情報であり、少なくともそれなりの信頼性はあるはずだが、必ずしも事実ではない可能性があることをご了承いただきたい。

LOL表現の歴史

(笑)

「(笑)」という表現は非常に古く、少なくとも1991年には既に見られる。 fjなどで見た記憶はないが、パソコン通信、ワープロ通信において黎明期から広く使われていたものと考えられる。

JIS X0208の括弧を使う「(笑)」は1998年頃から衰退。 1997年頃から入れ替わるように右括弧を省略する「(笑」が登場してくる。 1996年頃から「(爆)」「(涙)」「(泣)」といった表現が増えており、やがて右括弧省略形に発展するような形。

「(笑」のような右括弧省略形も割と息が長く、この表現の展は噂の「(暗黒微笑」なんかにつながっていく。

1997年頃にはサブカルチャー作品でこのようなネットスラングを使うキャラクターが登場する。

lol表現以外に様々な表現が可能なのがこの表現形式のメリットだが、絵文字の普及と共に廃れてゆく。

藁, ワラ

藁やワラといった表現が登場するには2000年頃から。 ローカルにはそれ以前から散見されるが、主には2chで流行している。

ちなみに、「(わら」を含めて「(笑)」を「わら」と読むようになるのは、1998年以降、ネットゲームにおいてであり、それ以前は(変換の都合もあるが)「わらう」と読むのが主流である。1999年頃になると対談記事などにおいても普通に「(笑)」が登場するようになるが、「わらう」とふりがなが振られている場合が多い。 (個人的には「わらい」と読んでいたが、やや少数派)

「わら」と読んでいたのは1999年以降の新参が多い印象だが、またたく間にこの読みが普及し、「わら」という音で表現されるようになる。

このことから藁、ワラといった表現が誕生する

wara, w

2chで使われるようになるより以前から、ネットゲームでは「わら」という読みが一般化しており、チャットでの変換の手間を省いて「わら」と表現されるケースが非常に多くみられる。

これは、チャットでのタイピングが行いづらいネットゲームの特性によるものだろう。一般的なチャットでは「わら」という読み及び表現は普及していない。

2000年以降に「w」が登場する。これはさらなる簡略化を求めて「w」だけを打ったものであり、「ローマ字入力変換なし」に由来するため、当時のMS-IMEに依存し全角である。

半角wが使われるようになるのは2003年以降。この頃にはネットゲームに限らず使われるようになっている。 特に若年層に浸透し、「(笑)」という表現は「ダサい」とされるようになる。

このときの若年層というのは基本的にケータイ(今で言うガラケー)ユーザーであるため、「w」を打つことは利便性がないどころか打ちにくいはずなのだが、広く使われていた。

この流行により急速に「藁」「ワラ」といった表現と廃れていき、また表記する場合でも括弧を伴わなくなっていく。

もっとも、若年層に浸透するよりも早く普及した2chにおいては「w」という表現は従来「(プゲラ」と表現されていたものに対応していたため、かなり強く嘲笑のニュアンスがあった。

ところが、2008年頃からこの事情は逆転していく。 つまり、「w」が徐々に(というより急速に)嘲笑としてのニュアンスなしに使われるようになり、逆に「(笑)」と閉じ括弧まで含めた形式が嘲笑のニュアンスで使われるようになる。

これはかなり複雑な経緯で、そもそも「(笑)と書くのはダサい」という風潮を前提として、(笑)という表現を馬鹿にして用いた、ということに由来し、これによって「(笑)と書くことによって馬鹿にしているニュアンスが伝わる」という状況が発生し、故に「(笑)という表現自体が嘲笑のニュアンスに見える」という変遷である。

これを踏まえてか、あるいは他の類推からか、括弧を伴わない「笑」という表現も増加する。 これが嘲笑のニュアンスなしに感情を伝える良い判断である、ということのようだ。

「w」を否定的に感じない人、というのは実のところ割と限られた文化圏であり、 一方でwや(笑)に対して嘲笑のニュアンスを取る人も意外と少ない。

とはいえ、「w」を重ねることで強く嘲笑のニュアンスを表現するということは今に言ったても行われているし、そのことを含めて「w」が「品のない発言である」と伝わること(こちらは嘲笑のニュアンスに関係なく、そのようにとる人が多い)も理解すべきであろう。 インターネットは自分の可視世界が全てではなく、公言することには責任がある。

草生える → 草

「wを重ねる」というのは、2ちゃんねるでも特に民度が低いとされた一部だけの文化だが、これに影響を受けたのがニコニコ動画である。

そして、ニコニコ動画において「wを重ねた状態」つまり「wwwwwww」が「草に見える」ことから、これを「草を生やす」と言われた。 あるいは、タイミングとしては判定しがたいが、2ちゃんねる内でそのような一部板以外で「w」を重ねることに対して「草を生やすな」という窘めが行われていることから、こちらが先行かもしれない。

いずれにしてもニコニコ動画が流行していた頃はユーザーは若年層が多く、「かなりの部分2ちゃんねるのユーザーとかぶっていた」ということであるらしい。

この場合の「草を生やす」は笑うことではなく、「wを重ねること」を述べているのだが、w自体が浄化された結果、「草生える」という表現が嘲笑のニュアンス関係なく(嘲笑の場合もあって)「笑える」「おもしろい」という言葉として使われるようになった。

これはそもそも感情にフィットする語感の良い言葉がなかったところへ、簡潔かつsound goodな言葉がついた形になる。

さらに発展し、「草生える=笑える」を「草」と表現するようになる。 草自体が「笑える」ことを示すようになると、「草を生やす」という表現は衰退。「草原」といった表現は減少しつつも、そのペースは「草を生やす」と比べると遅い。

ちなみに、この表現がoriginなわけではなく、これ以前の「ワロス」の置き換えであり、後には「こんなん笑うわ」(これも「こんなんわろてしまうわ」からの派生)も登場している。

「HTML」とwebの話

最近、「webエンジニアは閉じた世界しか見ていないのだろうか?」と感じるようなことがいくつもあった。

例えば

  • Ruby on RilasとRubyを混同する
  • JavaScriptとJQueryを混同する
  • 言語処理系と言語を混同する
  • 著名なフレームワークを使うのが当然であり、それ以外は存在しないものと考える
  • 全く異なる分野や利用法で使われている技術だということを頑なに認めない
  • 自分が勤めている会社の構造や手法や評価尺度が社会的絶対基準であると信じる

などだ。

で、今回は「HTMLとwebを同一視し、HTMLをwebだけのものであると考える傲慢さ」についてである。

HTMLの歴史と経緯

HTMLとwebは根本的には同一である、というのは正しい。

多くの人が知るとおり、webはCERNにおいて論文共有・参照手段として登場し、HTMLもまたこのために登場している。

HTMLはHyper Text Markup Languageなわけだが、「Hyper Text」とはなにかといえば、ハイパーメディアの一部たるテキストである。 じゃあハイパーメディアとはなにかといえば、multimediaに関連性をもたせたものである。

この場合、ハイパーメディアといいつつも現実的に考えられるのは画像くらいのものであった。 だが、潜在的には画像や動画を含めることができることを意識していた。

それらを文書でつなぐ、それがHTMLの役割である。 実際、HTMLのアンカーは「ハイパーリンク」と呼ばれている。

ここでは「マルチメディア」というのがテキスト、文書を含むものであることを忘れてはいけない。 これもまた当然に立派なメディウムである。

HTML2の時点では構造化文書であることが非常に強く意識されていた。 と、同時に、これが視覚的メディアであることもまた強く意識されていた。 この時点では論理性というよりも、視覚的意味合いによって構造化されるという感覚が強く、この過程は同じく論文のためのフォーマットとして誕生したTeXへの意識(あるいはroffへの意識)が感じられるものであった。

そう、ここまで構造化文書というのは、「章立て」といった概念はあるにせよ、文書自体が論理的構造を持っている、というのとは少々異なった。 論理的構造と視覚は一体だったのだ。これが当たり前のことであった。

HTML3によってこれは混迷を極めた。「webをリッチにしたい」という欲求はとどまることを知らず、JavaScriptが誕生し、より装飾的な機能が多く追加された。

一方で、HTML3時代には2つの、異なる意味が生まれていた。

ひとつは、web技術の応用だ。 webをあくまでWWWの世界に留めるのではなく、より広く使いたいという考え方があった。 既にWWWはインターネットの主要コンテンツであり、コンピュータはインターネットのためのものになりつつあった。 競争に勝ち抜くにはweb界の覇者となる必要があり、そのために力を注いだ技術を他のところでも使いたいと考えた、という流れだ。 例えばWindows 98のActive desktopなどがそれである。

もうひとつは、文書フォーマットとしてのHTMLの普及だ。 従来ドキュメントフォーマットというのはあまり良いものがなく、恐らく最善なのはPDFであり、そこにいたるまでのTeXであった。 Windowsは(docドキュメントを含め)いくつものドキュメントフォーマットを持っていたが、それらは標準化されておらず、Microsoftに閉じた存在であった。 roffはman roffであっても「イケてない」と考えられていた。 なにより最大の問題は表示向きでなく、HTMLは圧倒的に表示に適しているということだ。

だから、HTMLはヘルプドキュメントをはじめ、幅広く使われるようになった。 単にドキュメントファイルとして使われるだけではなく、様々なところで組み込まれて使われるようになった。

HTML4は決断のフォーマットであった。 HTMLはドキュメントフォーマットである、という立場を明らかにしたのである。

その上で拡張の余地として、

  • 動的要素を必要とする場合はクライアントサイドスクリプトを
  • 視覚的要素を必要とする場合はstylesheetを

使用するように求めた。 ちなみに、stylesheetとはイコールでCSSのことではなく、それがわからない人はJSSやXSLTについて調べておくとスムーズに理解が進むだろう。

HTML4は至ってstableであった。 諸々の問題はあれど、それらは取り込まれることなく進んでいた。 XHTMLにおける変更は、微々たるものであると言って差し支えあるまい。

だが、WWWの世界ではその間に様々なことがあった。 HTML4以降の歴史を動かしたのはGoogleであったと言って差し支えないだろう。 Ajaxが注目されるに至るまでの流れもGoogleのものであったし、HTML5策定時のGoogleに影響力は果てしなかった。

そして、Googleは明確な「オンライン派」である。 そもそもユーザーが直接にドキュメントを扱うことを良しとしない。だから、「HTMLをオンラインのものにしたい」と考えた。 これに対して反対する声、つまりレガシーなTeXのようなHTMLを尊重すべきだと言う声も強く、初期ではどちらかといえば「ドキュメントフォーマットである」という既定路線を維持する状況にあった。

だが、WWWがさらに成長し、webアプリケーションが基幹を握るに至り、すなわちGoogleが世界を支配するようになると否とは言えなくなってくる。 最初から「オンラインHTML」寄りだったAppleの存在の存在も多少あるが、この過程においての存在感は小さい。結局のところGoogleに対して否を唱えられる存在は既におらず、競争力という点も鑑みてMozillaがこれに同調したことにより、HTML5は「ウェブアプリケーションを提供する基盤」として位置づけられるようになった。実際、CSSには大手ウェブサイトが導入しているトレンドデザインをより簡単に書く方向となり、ウェブレンダリングの挙動はこれらを優先する(これらとことなるレイアウトデザインを許容しない)方向に振れた。

だが、必ずしもそれをよしとしない考え方もあって、HTML5というのは様々な思惑が混ざりあった言葉になった。

HTMLとCSSとJavaScript(ECMA Script)

HTMLとCSSはW3Cが、JavaScriptの仕様であるところのECMA Scriptの仕様はECMAが標準を策定している。

重要なのはこれらが「独立したもの」であるということである。 HTMLがCSSとJavaScriptと共に使わなければならないわけではないし、CSSがHTMLと共に使わなければならないわけではない。 それぞれが独立したものであり、これらは「ハンバーガーとポテトとコーラ」のような関係であるといっていいだろう。

独立した存在であるというのは、それ以外が存在しなくても成り立ち、なおかつそれ以外のものとも組み合わせられる、ということを意味している。

そもそもECMA Scriptに関していえば、JavaScriptの標準というわけでもない。 JavaScriptはECMA ScriptにないDOMに関する機能があり、こちらはW3Cが策定している。 結果として、JavaScriptに明確な言語仕様というものがなく、複数の(ある程度の互換性を持つ)実装が存在するに過ぎない。

ちなみに、「JavaScriptの実装」というと、「ChromeとFirefoxでしょ」と言う人がいるのだが、これは間違っている。 まず、Crhomiumが採用する(そしてNodeやElectronも使う)v8 JavaScriptエンジンがあるが、MozillaはC/C++で書かれたSpiderMonkey(Firefoxで使われているもの)のほかに、JavaでかかれたRihnoを持っている。 Safariが使っているJavaScriptエンジンはKJSソフトウェアがベースでv8とも別物。 Internet Explorerの最終的なエンジンはChakraで、Edgeも独自の実装(EdgeHTML)だった。さらに、OperaはPresto(JavaScriptエンジンのコードネームはCarakan)を採用していた。 Prestoは独自エンジンであり、プロプライエタリなので現存しないが、KJS SoftwareベースのJavaScriptエンジンを使うブラウザは(プロジェクトが生きているかどうかは置いておいて)存在するし、w3m-jsなんてものもあったりする。

webから独立したJavaScriptといえばRhinoを搭載するソフトウェアが実は結構多い。 Javaで書かれているアプリケーションから利用するのが割と簡単なので、SpiderMonkeyが圧倒的にウェブで使われているのに対し、Firefoxでは使われていないRhinoはアプリケーションでプラグイン機能を実現するために使われるようなことが多い。

また、Node.jsもv8ベースで有名な非ウェブのJavaScript利用例と言えるだろう。 ElectronになるとHTMLやCSSも含めてChromiumの機能を利用する形なので、非ウェブと言い切っていいのかどうか疑わしいが、それでも非WWWであるのは間違いない。

CSSに関してはほぼHTMLに依存している。XMLで使うこともできるのだが、この場合「XMLをHTML扱いする」という意図になってしまう。 このような場合はどちらかといえばXSLTが好ましく、XML CSSは基本的にウェブブラウザでXMLを表示するためのテクニックだ。

ただし、HTMLの外観を定義するのはCSSだけというわけではない。 JSS(JavaScript Stylesheet)というのもあるし、これ以外に関しても仕様上制約されているわけではない。 JSSが使われることはごく稀だが、実際に限定的なHTML(あるいはそのサブセット)に対しCSSでもJSSでもないスタイルシートを定義している場合が見られる。近年はレンダリング部分を既存のものに委ねる傾向が強くあまり見られなくなってきてはいるが。

HTMLの用途と位置づけ

ウェブにしか関心のない人は知らないかもしれないが、HTMLは広くドキュメントフォーマットなのである。

基本的なものであるにもかかわらず、ドキュメントフォーマットというのは今に至るまで以外なほど発展していない。 Microsoft Wordの強さというのもあるだろうが、ドキュメントフォーマットが「印刷向け」であるのも大きい。

純粋なドキュメントフォーマットとしては、現在使われるものとしては

  • PDF
  • PostScript
  • DVI
  • Microsoft Word
  • Open Docuemnt
  • RichText
  • roff
  • ePub
  • DocBook
  • HTML

あたり。 それらを生成するフォーマットは多くて

  • Markdown
  • GFM
  • PHP Markdown Extra
  • Pandoc Markdown
  • その他Markdown方言
  • ReSTructured text
  • TeX
  • LaTeX
  • POD
  • RDoc
  • Plain2
  • Asciidoc

などなどかりなたくさんある。

これらは「印刷か表示か」という点で性格の違いがある。 例えばLaTeXはプリプロセッサが処理するための正しい情報になる論理性があるが、出力自体は「太字」など視覚的な定義になっている。 これは、印刷してしまう場合、内部的にどのような情報を持っていたとしても失われてしまうことになるので、視覚的な表現が重要になるからだ。

manroffなどは端末上で表示するためのものだから、端末で表現可能な内容に偏っている。

Windowsヘルプフォーマット(.HLP.CHM)やDocBookなどは対応する環境が少ない。 結果的にオンラインドキュメント1で汎用性・交換性が高い形式というのはHTMLに限られてしまう。

次いでePubということになるだろうが、ePubは書籍を前提としており、オンラインドキュメントに最適化されているとは言い難い。2

この状況で、人に配布する整形済みドキュメントフォーマットとしては「HTMLが望ましく、HTMLしかない」という状況が存在している。 もちろん、ここではHTMLのサブセットはHTMLに内包するものとする。

webの世界というのはドキュメントを基本とするものであり、「みんなアプリケーションなんだからHTMLもアプリケーション化すべき」などというのは乱暴を通り越して愚かである。 HTMLの世界はwebに限らず広がっている、というのは、基礎教養と言えるだろうし、それ以上に自分の了見でのみ物事を定めようとすることを愚かと呼ばずしてなんと呼ぼうかという思いだ。


  1. オンラインドキュメントとは、コンピュータ上で読むドキュメントという意味であり、ウェブという意味ではない。

  2. ちなみに、ePubはそもそもXML/XHTMLベースであり、CSSを使用するものだから独立したフォーマットと呼べるかどうかはあやしい。

「シェル」と「端末(ターミナル)」の違いと詳細

【超ざっくり解説シリーズ】シェル(Shell)とは?シェルについて初心者にもわかりやすく解説するよというnoteを読み、ちょっと内容がひどかったので、Twitterで言及したものの、ちゃんと説明したほうがよかろうと考えて急遽、この記事を書くことにした。

「シェル」「端末」「端末エミュレータ」「端末デバイス」については、Mimir YokohamaのLinux基礎初級「シェルとコマンドライン」の中でやっている。 この内容をやる時期としてはかなり難しい部類に入り、かつ重要であることから、最近は端末デバイスを直接叩くといったことを含めて2時間以上じっくり取り組むことが多い。

内容自体はそれほど難しくはないと思うのだが、理解に至るには

  • 入出力
  • デバイスと接続
  • カーネルとシステムコール
  • プロセス
  • ファイルディスクリプタ
  • デバイススペシャルファイル

に対する理解が前提となるため、ちゃんと認識できていないと難しいかもしれない。

なお、このあたりはOSによって非常に大きな差異があるところなので、ここではLinuxを前提に説明する。 ここに書かれている内容では理解に至るには足りないと感じられる方は、ぜひMimir Yokohamaの授業を受けてみてほしい。 じっくりと丁寧な説明とハンズオンによって理解できるまでしっかりと授業を行っている。

カーネル

カーネルはCPUの特権モードで動作するプログラムである。

実際に定義としてはそれしかなく、カーネルが実際にどのような仕事を担っているかというのも特に決まってはいない。

とはいえ、カーネルにやってほしい重要なこととして「リソース管理」というものがある。 最近のOSはタイムシェアリングシステムなので物理的な装置数以上のプロセスを起動することができるから、プロセスが好き勝手にリソースを使ってしまうと色々奪い合ってしまうのだ。 一番わかりやすいのは、「ハードディスクのアームをどっち方向にどれだけ動かすか」というモーター制御を奪い合ってしまうという状況ではないだろうか。

というわけでリソース管理をするためにカーネルとしてはプロセス管理をしなければならぬ、ということになる。

だが、カーネルというのは基本的にそういうことをする。 つまり、コンピュータを使う上で必要な環境を整える、コンピュータという舞台を作る、というのがカーネルの仕事だ。 ここが改善されるとそれを使う全てが改善されるため開発にも力が入るというものだ。

端末とコマンドライン

カーネルはプロセスを起動する仕組みを提供し、起動したプロセスを管理してくれるのだが、ここで問題になるのは「どうやってプロセスを起動するか」だ。

Linuxの場合、カーネルロード時にinitというプログラムを実行し、initが色々なプログラムを実行するようになっているのだが、 これでは任意のタイミングで必要なプログラムを実行するという方法がない。 また、プロセスやカーネルにユーザーが対話的にやりとりする方法がない。

いや、実際にそう時代もあったのだ。 コンピュータがパンチカードマシンだった時代、プログラムを実行するというのはパンチカードを差し込んで読み込ませることだった。

だが、タイムシェアリングシステム時代になると、ユーザーとコンピュータは「やりとり」をする必要が生まれた。 それも、できるだけ使いやすく。

ここで使われるようになったのが「テレタイプ」である。

テレタイプというのは通信機能(送受信機能)をもったタイプライタである。 言ってみればモールス信号とFAXの中間みたいな感じで、電話回線を通じて(手動交換機を通じて)ほかのテレタイプの紙に印字できる。

テレタイプ自体は1920年代には存在していたもので、1960年代にコンピュータに接続して使われるようになった。 当時の「最もポピュラーのコンピュータとユーザーが意思疎通するための機械」だったのだ。

ユーザーは、タイプライタ同様にテレタイプでタイピングをする、あるいは予め打ち込んで紙テープに出力したものを読み込ませることでコンピュータに対して意思を伝える。 コンピュータからの出力はテレタイプを通じて紙に印字される。

この仲介をするのがシェルなわけだけれども、この時点ではシェルと呼ぶようなものは必ずしも必須だったわけではなく、単純にテレタイプ・インタープリターのようなものであったし、 それ自体が「OS」と呼ばれることが多かった。

Linuxでも端末のことをテレタイプ(tty)と呼ぶが、実はUnixですらテレタイプは過去のものだった。 1970年代にはビデオディスプレイ端末が登場しており(Unixは1973年に登場)、Unixの端末というと紙テープではなく画面を使うもののイメージが強い。

紙テープから画面になることの違いは、「入出力環境が複数行になる」ということである。 例えばUnixのエディタコマンドとしてex(1)とvi(1)がある。 ex(古くはe, そしてee, ed)はラインエディタであり、一行で入出力ができる。つまり、紙テープに適している。 だが、ビデオディスプレイなら複数行を表示し、それを見ながら編集できる。それがvi(VIsual)なのである。

そして、もうひとつ大きな点として「表示上での削除が可能になる」ということがある。

だから、キーボードから打ったものをそのまま解釈してプロセスを起動する、という方法より「よりよい方法」が登場する。 それが「コマンドライン」である。

コマンドラインは、ユーザーはその意図を「行」に記述することができる。 行単位なので、改行したときがその意思の確定である。

このコマンドラインを快適なインターフェイスとして利用できるようにしたのが「シェル」である。

シェル

コマンドラインの基本的な考え方は前述の通りだが、Unix原初のシェルであるshは

  • 行を編集する機能
  • コマンドラインで複数のプロセスを起動する操作
  • ファイルディスクリプタをファイルに対して再オープンする操作
  • 出力ファイルディスクリプタを別のプロセスの入力ファイルディスクリプタへのパイプにする操作

など様々な機能を搭載した「超高機能インターフェイス」であった。 ユーザーは1行の「コマンドライン」の中で実に様々な操作を行うことができる。

今にすればshなんて貧弱極まりないのだが、当時の感覚からすれば「キーボードから打ったものがそのままコンピュータの動作になる」などというのと比べ信じられないほどいろんなことができ、様々に応用できるスグレモノだったのだ。

これがスグレモノである点として、「プログラムを記述する必要性が下がる」というのがある。 インターフェイスが単にキーボードから打った内容に基づきプロセスを起動するだけであるならば、全ての操作は事前にプログラムを用意しておかなければ行えない。 shは実に様々な操作をsh自身によって提供し、なにより応用が効くようになっていたので、圧倒的にプログラムを書くのではなくコマンドラインを打つことで目的を達成できるようになったのだ。

基本的には、bashであれ、zshであれ、それらの「機能が豊富で便利」という点を強化したにすぎず、基本的には変わらない。 シェル自身もプログラムであり、別に特別なものではない。ただ、「インターフェイスが何もなければ対話的にコンピュータを使うことはできないが、シェルはただ対話的に使えるだけでなく、対話的に 便利に 使えるインターフェイスだ」というだけの話である。

カーネルに対して特別にくっついているわけではないし、Linuxシェルはユーザースペースで動作し、別にシステムコールを直に叩くわけではなく汎用性のあるライブラリ(例えばglibc)をロードし、実行する「対話的プログラム」でしかない。

ただ重要な点がある。シェルが登場したとき、コンピュータとやりとりするための機械はテレタイプ、あるいはビデオディスプレイ端末であった、ということだ。

Unixはそれがどちらであっても、あるいはどこのメーカーのテレタイプであっても抽象的に扱えるように「デバイスファイル」という仕組みによって扱うようになっている。 そのため、「端末デバイス」という抽象化したレベルで取り扱うことができ、この端末デバイスは、テレタイプのような一行のものなのか、あるいはビデオディスプレイ端末のような複数行のものなのか、という情報と合わせて取り扱うことができる。

現在は端末デバイスではなく、ビデオデバイスを通じて出力し、キーボードを通じて入力するのが普通だ。 これは一般的には「X Server→ビデオデバイス(カーネルインターフェイス)→ビデオドライバ(カーネル)→ビデオカード(ハードウェア)」の構成であるが、シェルは依然として端末デバイスを必要とする。 普通、シェルは直接にX Server、あるいはビデオデバイスを扱う機能はもたされておらず、あくまでも端末デバイスを使って入出力を行うようになっている。

端末、仮想端末

だが、現在本当に端末に繋がっているコンピュータなんてまずないので、物理的に端末を意味する端末デバイスファイルが用意できない。

そこで、実際には端末はなくても、端末デバイスとして扱える仮想端末デバイスと、コマンドラインの入出力に適した仮想端末ソフトウェアが使用される。

「テキストモード」においては、「仮想コンソール」と呼ばれることが多いプログラムを使用する。 このプログラムは、ビデオデバイスによってテキストビデオモードを設定すると共に、(テキストビデオモードの)ビデオデバイスを通じた画面出力と、キーボード入力の処理機能、 そして仮想端末デバイスの提供(Linuxでは/dev/tty*)を行う。 その上でシェルを起動すれば、シェルは/dev/tty?を端末として扱うことができるわけだ。

ターミナルエミュレータは単なるX client(あるいはWaylandクライアント)である。 つまり、グラフィカルアプリなのだが、これはこれで仮想端末を提供する。Linuxでは/dev/pts/*である。 やはり、この上でシェルを起動すれば、シェルは/dev/pts/?を端末として扱うことができる。

だから、例えば

% ls -l /proc/$$/fd/0
lrwx------ 1 haruka haruka 64  6月  1 00:19 /proc/2835/fd/0 -> /dev/pts/0

ということである。

なお、端末エミュレータはキーボードを処理しない。X serverから受け取ったキー入力を仮想端末デバイスを通じて入力するようになっている。 だから、「シェルの標準入力はデフォルトでキーボードに繋がっている」というのは嘘で、対話的シェルは入出力ともに端末デバイスに繋がっている。 仮想コンソールの場合、シェル→端末デバイス→仮想コンソール→キーボードと間接的につながっているのだが、ターミナルエミュレータの場合は全く繋がっていない。

ちなみに、「端末」といえば、DECのVT-100である。 1978年にリリースされたビデオディスプレイ端末で、まぁとにかく売れに売れて、端末といえばVT-100というレベルだった。

だから、VT-100の仕様が一般的で、VT-100と互換仕様の端末も出たし、仮想端末もだいたいVT-100と互換になっていたりする(そして、その設定がある)。

そして、もうひとつ。

xtermは、それを端末として扱うための色々なものを、自前でもっていたりする。