これで基本的なことは分かってもらえただろうか。キーボードとコンソール アプリケーションの間にはボトルネックがある。つまり、 ASCII 文字列でしかやり取りできない部分があるのだ。 だから、特殊キーをやり取りするには、まず keysym から ASCII 文字列に変換し、しかるのちにキー特性へ変換するという作業が必要になる。 コンソールが異なれば、キーの変換方式も変わってくる。というわけで、 端末データベースの出番となるわけだ。端末データベースを作成すれば システムは問題なく動作するだろうが、小さな問題が 1 つ残る。 つまり、端末データベースがいつも正しく設定されているとは限らないし、 全員が同じデータベースを使うわけでもないということだ。
アプリケーションは、データベースに登録されたエントリのうちの どれを使うかを、何らかの方法で知る必要がある - これは TERM 環境変数を適切に設定することで実現する。だが時に、端末エミュレータと TERM によって示されたデータベースエントリの内容との間に 不一致があることがある。
もっと言えば、多くのアプリケーションは端末データベースを 使わない (か、少なくとも全部は使わない)。そして、 BS や DEL の ASCII コードを 勝手に解釈する - つまりデータベースを見ずに、それらが本来持つべき意味を 割り当てるのだ (通常ならば当然このセマンティクスの意味は、カーソルの前 あるいは下で文字を削除することだ)。その結果我々の美しいシステムは完全に 壊れてしまうわけだ (全ての Linux ユーザーが苦い経験をしたことがあるように)。 例えば bash は DEL を backward-delete-char すなわちバックスペースすべきと想定する。 だからインストールしたばかりのコンソールの上では Backspace キーは予想通りの動作をする。2 回のあべこべが重なりあったからだ! 当然、Delete キーは動かない。これは bash が 端末データベースを見ていないので、 kdch1 特性であることがわからないからだ。
どれだけ物事がこんがらがってしまっているかを表す一例として、 Red Hat ディストリビューション (多分他のにも) に含まれている fix_bs_and_del スクリプトを考えてみよう。 それはその場しのぎに BackSpace keysym を Backspace キーに割り当て、Delete keysym を Delete キーに割り当てる。これでシェルが動くようになった! でも今度は不幸なことに keysym 生成と端末データベースの正しい 組み合わせに頼っているプログラムが全てまったく動かなくなってしまう。 Delete keysym が DEL にマップされ、 それが今度は terminfo データベースの kbs キー特性に マップされてしまうために、両方のキーがバックスペースを発生させてしまうからだ。