In Terminal I cannot type lowercase e

Question

If I open a Terminal window and I type the letter "e" (without quotes of course) it beeps and will not type the letter. Every other letter works just fine in Terminal. Uppercase E works too. Just the lowercase e doesn't.

In every other app on my computer lowercase e works without issue, so it's not a keyboard issue.

This started sometime in the last week. I use Terminal a lot in my job and never has this been an issue. I have rebooted (did not fix). I have reset terminal (did not fix).

Since I do not know the exact date when this started, I am not sure if I made any changes or installed software. I am trying to remove anything I have installed recently.

FYI I have tried to use the 3rd party iTerm2 and it does the same thing.

ALSO - if I paste in something with a lower e, it does same thing - will not take it. It has to be some terminal bash config issue I would think.

In fact, I copied the following sense and then I pasted it in Terminal. What appears? sns and you can hear two beeps.

Also - in case it is unclear - this happens with the built-in keyboard on the MBP as well as an external keyboard. Based on that and the pasting issue, I do not think this is a physical keyboard issue in any way.

Specs: 2015 MacBook Pro, fully up to date OS X

Answer 1

Let's debug it.

1. Change shells and try again. (Credit to @Kent) In terminal:
   • $(which zsh)
2. Comment out all lines in .bash_profile, .bashrc, etc. and open a new terminal tab/window. If this resolves the issue, something being loaded into the shell environment is consuming the letter e for reasons that science may never be able to explain.
3. Try cating a file that contains the letter e to see if it will even display: (Credit to @techraf)
   • Open a text editor (not terminal)
   • Enter some text with a few es and save file (foo.txt?)
   • In terminal, cat the file:
     • cd /path/to/folder; cat foo.txt
   • If es render then the terminal can handle it, if not, then this is super weird.

4. Try applescript. (Credit to @ALX)

   • Open Applescript editor

   • Create Applescript file with these contents:

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

   • Execute the script file and then quickly navigate to the terminal window. In a few seconds it will virtually press the e key and hopefully show up in your terminal. This would indicate that there could be an input/device driver issue (though I am clueless as to what that might be)

I'm not going to lie, I am absolutely fascinated by this issue and cannot wait to learn what the cause is. It's not hardware because it works in other applications, which means it's software and I cannot imagine who would swallow the letter e with code.

Answer 2

I just found this thread after running into the same issue.

Try escaping use of e by prefixing with Ctrl+v (^v).

Quick debug

(In Bash), bind -p |grep -iE '"[AE]"' shows

bash-$ bind -p | grep -iE '"[AE]"'
"A": self-insert
"E": self-insert
"a": self-insert
"e": self-insert

If that last "e": self-insert line is missing, this solution applies.

Quick fix

Escape each use of e by prefixing with Ctrl+v. Rebind in shell (quoting, both, is critical):

• bind '"e": self-insert', but escaping each e.

• bind '"^ve": s^velf-ins^vert'

Fix files

• Check ~/.inputrc (or /etc/inputrc) for incorrectly formatted lines.
• Check sourced bash config files for bind '[set stmt]' statements with incorrect formatting.

Explanation

.inputrc

I had 2 lines in .inputrc, added in a moment of careless ignorance, beginning with e and s (which are valid bash config, but not valid readline config). They seem to have been interpreted as keybinding-aliases for readline customization.

Removing the lines from .inputrc, I have confirmed, solved my problem.

Thanks @user208052 for the relevant reminder to check .inputrc.

The shell's Readline configuration

The shell's bind command allows viewing and modification of Readline config. (See help bind. help is man for shell-internal commands).

View bind -p (maybe pipe to less |less or redirect to a file > binds.txt). It "list[s] functions and bindings in a form that can be reused as input".

It has entries like "c": self-insert for every character in the ASCII range, so the screwed up config may replace self-insert with some other Readline function.

It's got some gems; viewing it just taught me that C-= (\e=) prints possible completions, in my default configuration. It seems to show the complete current configuration of Readline for your shell...pretty useful and powerful. Good for exploring.

End to end test

1. e works

2. insert erroneous line in .inputrc, open new shell

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

3. e is apparently a no-op

4. bind -p (| grep -i '"E"') shows

• "E": self-insert,
• but no "e": self-insert
• whereas "A": self-insert and "a": self-insert are present.

Answer 3

I'm a bit rusty, but pasting in Terminal works differently than pasting in a GUI program: each character is sent as a separate keystroke, not as a memcopy from clipboard to app buffer. So if the "e" has been remapped, it will be remapped in the paste as well.

Check the following locations:

System Preferences > Keyboard > Shortcuts

~/Library/KeyBindings/KeyBindings.dict

$ defaults read com.apple.Automator NSUserKeyEquivalents

Answer 4

Something else you can try, is to set the Terminal to open up a text editor (emacs, vi, etc) when a new window is opened. For example, in the Terminal preferences for "Shell", you can have it Run command such as /usr/bin/emacs. If you can't enter e in the preference pane, then something even odder than what's been proposed so far is going on...

When a new Terminal window is opened, emacs will should start, and you can try to press e etc. I have no idea what will happen, but like @Pierce above, I'm curious as to what is possibly going on.

Answer 5

Check the stty setting and make sure 'e' didn't accidentally get set as the backspace or similar. Been there, done that. Stty something \e Would do it The recommendation to disable/comment out .bash* would also probably uncover it.

Answer 6

I had the same problem which was caused by having a typo in /etc/inputrc:

et output-meta on

instead of

set output-meta on

Answer 7

Oddly I just had this come up running macOS 10.13.6 on a MacBook Air. One user was fine, the admin user terminal running bash would not accept the lowercase letter 'a'- not typing, not pasting, etc. Running zsh it would be fine. Other users, fine. I think this had happened before and fixed it by deleting /Users/admin/.inputrc file, and .bash_profile. I re-added them and it works. Oddly there is nothing important in these files. .inputrc is just "set completion-ignore-case On", and there are a couple of command line aliases in .bash_profile. Honestly something else might be up but works for now.

I seem to remember having to delete and re-add these files over this issue. Well, these files might trigger or reset the issue at least.

Answer 8

I had this same problem using Tilix, after no success using the above suggestions, I went into the Tilix preferences and then into Shortcuts. At the very bottom of the list, it has "Profile, Default" and the Shortcut K was E (actually lowercase e), I changed that to Z and now I could type the lower case e, but not lower case z, so I reset the Shortcut again to Ctrl+Alt+E and this solved my problem.

Answer 9

Just delete .inputrc file, it's in root directory. (It's a hidden file).