14

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 May 11 '16 at 22:13
  • 1
    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 May 11 '16 at 22:28
  • 1
    What happens if you cat filnam.txt where the file called filnam.txt contains some ASCII text with e? – techraf May 11 '16 at 23:24
  • Is this only in the shell or in any program running in Terminal? – agentroadkill May 12 '16 at 6:31
7

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 – user151019 May 12 '16 at 10:12
  • 1
    Yeah, I'm actually FASCINATED by this issue – Manchineel May 13 '16 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 May 16 '16 at 17:56
3

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

.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.
2

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

  • Check for what exactly? – nohillside May 12 '16 at 8:45
  • Whether the e key has been remapped. – zencraft May 13 '16 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 May 14 '16 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 May 18 '16 at 16:49
1

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.

0

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.

0

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
-1

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 .