Si j'ouvre une fenêtre de terminal et que je tape la lettre "e" (sans guillemets bien sûr), elle émet un bip et ne tape pas la lettre. Toutes les autres lettres fonctionnent très bien dans Terminal. E majuscule fonctionne aussi. Ce n'est pas le cas des e minuscules.

Dans toutes les autres applications de mon ordinateur, les e minuscules fonctionnent sans problème, ce n'est donc pas un problème de clavier.

Cela a commencé au cours de la dernière semaine. J'utilise beaucoup Terminal dans mon travail et cela n'a jamais posé de problème. J'ai redémarré (pas résolu). J'ai réinitialisé le terminal (n'a pas résolu).

Comme je ne connais pas la date exacte à laquelle cela a commencé, je ne sais pas si j'ai apporté des modifications ou installé un logiciel. J'essaie de supprimer tout ce que j'ai installé récemment.

Pour info j'ai essayé d'utiliser l'iTerm2 tiers et ça fait la même chose.

ÉGALEMENT - si je colle quelque chose avec un e inférieur, il fait la même chose - ne le prendra pas. Je pense que ce doit être un problème de configuration de bash terminal.

En fait, j'ai copié le sens suivant , puis je l'ai collé dans Terminal. Qu'est-ce qui apparaît? sns et vous pouvez entendre deux bips.

En outre - au cas où cela ne serait pas clair - cela se produit avec le clavier intégré sur le MBP ainsi qu'avec un clavier externe. Sur la base de cela et du problème de collage, je ne pense pas que ce soit un problème de clavier physique en aucune façon.

Spécifications: MacBook Pro 2015, entièrement à jour OS X

Déboguons-le.

1. Changez de coquille et réessayez. (Crédit à @Kent) Dans le terminal:
   • $(which zsh)
2. Commentaire sur toutes les lignes .bash_profile, .bashrcetc. et ouvrez un nouvel onglet Terminal / fenêtre. Si cela résout le problème, quelque chose en cours de chargement dans l'environnement shell consomme la lettre epour des raisons que la science ne pourra peut-être jamais expliquer.
3. Essayer catun fichier contenant la lettre epour voir si elle s'affichera: (Crédit à @techraf)
   • Ouvrez un éditeur de texte (pas un terminal)
   • Entrez du texte avec quelques es et enregistrez le fichier ( foo.txt?)
   • Dans le terminal, catle fichier:
     • cd /path/to/folder; cat foo.txt
   • Si ele rendu est alors le terminal peut le gérer, sinon, c'est super bizarre.

4. Essayez applescript. (Crédit à @ALX)

   • Ouvrez l'éditeur Applescript

   • Créez un fichier Applescript avec ces contenus:

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

   • Exécutez le fichier de script, puis accédez rapidement à la fenêtre du terminal. En quelques secondes, il appuiera virtuellement sur la etouche et, espérons-le, apparaîtra dans votre terminal. Cela indiquerait qu'il pourrait y avoir un problème de pilote d'entrée / périphérique (bien que je ne sache pas ce que cela pourrait être)

Je ne vais pas mentir, je suis absolument fasciné par ce problème et j'ai hâte d'en connaître la cause. Ce n'est pas du matériel, car il fonctionne dans d'autres applications, ce qui signifie que c'est un logiciel et je ne peux pas imaginer qui avalerait la lettre eavec du code.

Je viens de trouver ce fil après avoir rencontré le même problème.

.inputrc

J'ai eu 2 lignes .inputrc, ajoutées dans un moment d'ignorance négligente, en commençant par eets (qui sont une configuration bash valide, mais pas une configuration readline valide). Ils semblent avoir été interprétés comme des alias de liaison de touches pour la personnalisation de la ligne de lecture.

La suppression des lignes de .inputrc, j'ai confirmé, a résolu mon problème.

Merci @ user208052 pour le rappel pertinent à vérifier .inputrc.

Configuration Readline du shell

La bindcommande du shell permet de visualiser et de modifier la configuration de Readline. (Voir help bind. helpEst manpour les commandes internes au shell).

Afficher bind -p(peut-être |lessrediriger vers moins ou rediriger vers un fichier > binds.txt). Il "liste les fonctions et les liaisons sous une forme qui peut être réutilisée en entrée" .

Il a des entrées comme "c": self-insertpour chaque caractère de la plage ASCII, donc la configuration vissée peut remplacer self-insertpar une autre fonction Readline.

Il a des gemmes; le visualiser m'a juste appris que C-=( \e=) imprime des complétions possibles, dans ma configuration par défaut. Il semble montrer la configuration actuelle complète de Readline pour votre shell ... assez utile et puissant. Bon pour explorer.

Test de bout en bout

1. e travaux

2. insérer une ligne erronée .inputrc, ouvrir un nouveau shell

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

3. e est apparemment un no-op

4. bind -p( | grep -i '"E"') montre
   • "E": self-insert,
   • mais non "e": self-insert
   • tandis que "A": self-insertet "a": self-insertsont présents.

Je suis un peu rouillé, mais le collage dans Terminal fonctionne différemment du collage dans un programme GUI: chaque caractère est envoyé sous forme de séquence de touches distincte, et non sous forme de memcopy du presse-papiers vers le tampon de l'application. Donc, si le "e" a été remappé, il sera également remappé dans la pâte.

Vérifiez les emplacements suivants:

System Preferences > Keyboard > Shortcuts

~/Library/KeyBindings/KeyBindings.dict

$ defaults read com.apple.Automator NSUserKeyEquivalents

Vous pouvez également essayer de configurer le terminal pour qu'il ouvre un éditeur de texte (emacs, vi, etc.) à l'ouverture d'une nouvelle fenêtre. Par exemple, dans les préférences du terminal pour "Shell", vous pouvez lui demander d' exécuter la commande telle que /usr/bin/emacs. Si vous ne pouvez pas entrer edans le volet des préférences, alors quelque chose d'encore plus étrange que ce qui a été proposé jusqu'à présent se passe ...

Quand une nouvelle fenêtre du terminal est ouvert, emacs se doit commencer, et vous pouvez essayer d'appuyer sur eetc. je ne sais pas ce qui se passera, mais comme @Pierce ci - dessus, je suis curieux de savoir ce qui est peut - être en cours.

Vérifiez le paramètre stty et assurez-vous que «e» n'a pas été accidentellement défini comme espace arrière ou similaire. J'y suis allé, j'ai fait ça. Stty quelque chose \ e le ferait La recommandation de désactiver / commenter .bash * le découvrirait probablement aussi.

J'ai eu le même problème qui a été causé par une faute de frappe dans /etc/inputrc:

et output-meta on

au lieu de

set output-meta on

Étrangement, je viens de lancer ce macOS 10.13.6 sur un MacBook Air. Un utilisateur allait bien, le terminal utilisateur administrateur exécutant bash n'accepterait pas la lettre minuscule «a» - ne pas taper, ne pas coller, etc. En exécutant zsh, ce serait bien. D'autres utilisateurs, très bien. Je pense que cela s'était déjà produit auparavant et l'a corrigé en supprimant le fichier /Users/admin/.inputrc et .bash_profile. Je les ai rajoutés et ça marche. Curieusement, il n'y a rien d'important dans ces fichiers. .inputrc est simplement "set complete-ignore-case On", et il y a quelques alias de ligne de commande dans .bash_profile. Honnêtement, quelque chose d'autre pourrait être en place mais fonctionne pour l'instant.

Je me souviens avoir dû supprimer et rajouter ces fichiers sur ce problème. Eh bien, ces fichiers pourraient au moins déclencher ou réinitialiser le problème.

Supprimez simplement le fichier .inputrc, il se trouve dans le répertoire racine. (C'est un fichier caché).