ターミナルウィンドウを開いて文字「e」を入力すると（もちろん引用符なし）、ビープ音が鳴り、文字は入力されません。他のすべての文字は、ターミナルで正常に機能します。大文字のEも機能します。小文字のeはそうではありません。

コンピューター上の他のすべてのアプリでは、小文字のeが問題なく機能するため、キーボードの問題ではありません。

これは先週のいつかから始まりました。私は仕事でターミナルをよく使いますが、これが問題になることはありません。再起動しました（修正しませんでした）。ターミナルをリセットしました（修正しませんでした）。

これが開始された正確な日付がわからないため、変更を加えたのか、ソフトウェアをインストールしたのかわかりません。最近インストールしたものをすべて削除しようとしています。

参考までに、サードパーティのiTerm2を使用しようとしましたが、同じことを行います。

また-より低いeで何かを貼り付けても、同じことを行います-それを受け取りません。それは私が考えるだろういくつかのターミナルバッシュの設定の問題でなければなりません。

実際、次の意味をコピーして、ターミナルに貼り付けました。何が表示されますか？ snsとビープ音が2回聞こえます。

また、不明な場合-これは、MBPの組み込みキーボードと外部キーボードで発生します。それと貼り付けの問題に基づいて、これは決して物理的なキーボードの問題だとは思いません。

仕様：2015 MacBook Pro、完全に最新のOS X

デバッグしましょう。

1. シェルを変更して再試行してください。（@Kentへのクレジット）ターミナル内：
   • $(which zsh)
2. 内のすべての行をコメントアウトし.bash_profile、.bashrcなどと新しいターミナルタブ/ウィンドウを開きます。これで問題が解決した場合、シェル環境に読み込まれているものがe、科学では説明できない理由で文字を消費しています。
3. cat文字が含まれているファイルを試しeて、表示されるかどうかを確認してください：（Credit to @techraf）
   • テキストエディタを開きます（ターミナルではありません）
   • 数e秒でテキストを入力し、ファイルを保存します（foo.txt？）
   • ターミナルでcatは、ファイル：
     • cd /path/to/folder; cat foo.txt
   • esがレンダリングされれば、端末はそれを処理できますが、そうでなければ、これは非常に奇妙です。

4. applescriptを試してください。（@ALXへのクレジット）

   • Applescriptエディターを開く

   • 次の内容のApplescriptファイルを作成します。

     delay 10
     tell application "System Events" to keystroke "e"

   • スクリプトファイルを実行し、すぐにターミナルウィンドウに移動します。数秒でeキーが事実上押され、うまくいけば端末に表示されます。これは、入力/デバイスドライバーの問題がある可能性があることを示します（ただし、それが何であるかについてはわかりません）

私は嘘をつくつもりはありません、私はこの問題に絶対に魅了され、原因が何であるかを学ぶのを待つことができません。他のアプリケーションで動作するため、ハードウェアではありません。つまり、ソフトウェアでありe、コードで文字を誰が飲み込むか想像できません。

同じ問題に遭遇した後、このスレッドを見つけました。

.inputrc

私は中2つのラインを持っていた.inputrc、、不注意な無知の瞬間には追加 で始まるeとs（有効なのreadlineの設定有効なbashの設定ファイルである、ではありません）。これらは、readlineのカスタマイズ用のキーバインディングエイリアスとして解釈されたようです。

から行を削除して.inputrc、問題を確認、解決しました。

確認する関連するリマインダーを@ user208052に感謝し.inputrcます。

シェルのReadline設定

シェルのbindコマンドを使用すると、Readline構成を表示および変更できます。（参照してくださいhelp bind。helpあるmanシェルの内部コマンドのため）。

表示bind -p（おそらくlessにパイプする|lessか、ファイルにリダイレクトします> binds.txt）。それは「入力として再利用できる形式で関数とバインディングをリストします」。

"c": self-insertASCII範囲内のすべての文字のようなエントリがあります。そのため、設定がself-insertめちゃくちゃになると、他のReadline関数に置き換わる場合があります。

いくつかの宝石があります。それを見ると、デフォルトの構成でC-=（\e=）が補完候補を出力することがわかりました。お使いのシェルのReadlineの現在の完全な構成を示しているようです...かなり便利で強力です。探索に適しています。

エンドツーエンドのテスト

1. e 働く

2. に誤った行を挿入し.inputrc、新しいシェルを開きます

   et completion-map-case on
   set completion-ignore-case on

3. e 明らかにノーオペレーションです

4. bind -p（| grep -i '"E"'）ショー
   • "E": self-insert、
   • でもない "e": self-insert
   • 一方、"A": self-insertと"a": self-insertが存在します。

私は少しさびていますが、ターミナルでの貼り付けはGUIプログラムでの貼り付けとは異なります。各文字は、クリップボードからアプリバッファーへのmemcopyとしてではなく、個別のキーストロークとして送信されます。そのため、「e」が再マッピングされた場合は、ペーストでも再マッピングされます。

次の場所を確認してください。

System Preferences > Keyboard > Shortcuts

~/Library/KeyBindings/KeyBindings.dict

$ defaults read com.apple.Automator NSUserKeyEquivalents

他に試すことができるのは、新しいウィンドウが開いたときにテキストエディター（emacs、viなど）を開くようにターミナルを設定することです。たとえば、「シェル」のターミナル設定では、などのRunコマンドを実行できます/usr/bin/emacs。e環境設定ペインに入力できない場合、これまでに提案されているものよりもさらに奇妙なことが起こっています...

新しいターミナルウィンドウが開かれると、emacs が起動し、eなどを押すことができます。何が起こるかわかりませんが、上記の@Pierceのように、何が起こっているのか興味があります。

stty設定を確認し、「e」が誤ってバックスペースなどに設定されていないことを確認します。そこに行って、それをしました。.bash *を無効化/コメントアウトすることを推奨すると、おそらくそれも明らかになるでしょう。

にタイプミスがあることによって引き起こされた同じ問題がありました/etc/inputrc：

et output-meta on

の代わりに

set output-meta on

奇妙なことに、MacBook AirでmacOS 10.13.6を実行するようになりました。1人のユーザーは問題ありませんでした。bashを実行している管理ユーザー端末は、小文字の「a」を受け入れません。入力も貼り付けもしないなどです。zshを実行すると問題ありません。他のユーザー、結構です。これは以前に発生したもので、/ Users / admin / .inputrcファイルと.bash_profileを削除することで修正されたと思います。私はそれらを再び追加し、それは動作します。奇妙なことに、これらのファイルには重要なものは何もありません。.inputrcは「set completion-ignore-case On」であり、.bash_profileにはいくつかのコマンドラインエイリアスがあります。正直なところ、他の何かが起きているかもしれませんが、今のところは機能します。

この問題に関してこれらのファイルを削除して追加し直さなければならなかったことを覚えているようです。さて、これらのファイルは少なくとも問題を引き起こしたりリセットしたりするかもしれません。

.inputrcファイルを削除するだけで、ルートディレクトリにあります。（隠しファイルです）。