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

  • 1
    Does the behavior persist if you go to another shell, like csh or tcsh?
    – Kent
    Commented May 11, 2016 at 22:13
  • 2
    That's weird... try opening applescript by searching it in spotlight, and type in delay 10 then press return and write tell application "System Events" to keystroke "e" exactly as written. When play is pressed it will wait 10 seconds, and then press e by itself. Go to terminal before that time expires and test it. If that doesn't work, than you have a serious internal problem with your computer.
    – ALX
    Commented May 11, 2016 at 22:28
  • 1
    What happens if you cat filnam.txt where the file called filnam.txt contains some ASCII text with e?
    – techraf
    Commented May 11, 2016 at 23:24
  • See linuxquestions.org/questions/slackware-14/… Commented May 12, 2016 at 2:47
  • Is this only in the shell or in any program running in Terminal? Commented May 12, 2016 at 6:31

9 Answers 9


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.

  • 1
    Better to try a C shell e.g. tcsh as it won't (can't) read the bash startup files or even just start an interpreter e.g. python on perl and type in there
    – mmmmmm
    Commented May 12, 2016 at 10:12
  • 1
    Yeah, I'm actually FASCINATED by this issue
    – Manchineel
    Commented May 13, 2016 at 22:41
  • "I cannot imagine who would swallow the letter e with code" This guy might know something...upload.wikimedia.org/wikipedia/en/5/5e/Cisforcookie.jpg
    – Allan
    Commented May 16, 2016 at 17:56

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.



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.

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


$ defaults read com.apple.Automator NSUserKeyEquivalents

  • Check for what exactly?
    – nohillside
    Commented May 12, 2016 at 8:45
  • Whether the e key has been remapped.
    – zencraft
    Commented May 13, 2016 at 22:38
  • 1
    Assuming that the OP isn't too experienced in such things: what exactly should they look for? An example of such a mapping might be helpful.
    – nohillside
    Commented May 14, 2016 at 3:57
  • 1
    For Keyboard Shortcuts, look for key remappings: there's an app list on the left and a shortcut list on the right. Make sure that Terminal is not in the app list. The other two should be empty; if KeyBindings.dict exists or the defaults command returns something, post it here for further analysis.
    – zencraft
    Commented May 18, 2016 at 16:49

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.


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.


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

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.


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.


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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .