Tout utilisateur de Linux a tôt ou tard été confronté à une situation dans laquelle il semblait impossible d'avoir des touches Backspace et Suppr qui fonctionnent, en console comme sous X. Cette page explique ce phénomène et y suggère des solutions. Dans l'ensemble, les notions abordées ici sont indépendantes de la distribution utilisée : mais en raison de l'étendue des différences entre les fichiers de configuration du système selon les distributions, j'essaierai de donner au lecteur suffisamment de connaissances pour concevoir ses propres réglages en cas de besoin.

Je suppose que la touche Backspace doit revenir d'un caractère puis effacer le caractère qui est placé sous le curseur. Au contraire, la touche Suppr doit effacer le caractère qui est placé sous le curseur, sans que ce dernier ne bouge. Si vous pensez que la fonction des deux touches doit être intervertie, en dépit du fait que la majorité des claviers fournisse une flèche orientée vers la gauche (←) sur la touche Backspace, alors cette page ne vous donnera pas de solutions immédiates, mais vous pourrez néanmoins trouver très utiles les explications données ici.

Je suppose également que les réglages ne devraient modifier que des fichiers locaux (d'un utilisateur). Aucune partie standard de la distribution ne devrait être altérée. Enfin, ce document traite de la façon dont il faut configurer votre système pour que les applications reçoivent les bons événements clavier. Si une application décide d'interpréter de tels événements d'une façon idiosyncratique, le seul réglage possible est de reconfigurer l'application.

Note

Depuis la première version de ce petit guide pratique, les choses se sont encore embrouillées. Différentes distributions d'un même émulateur de terminal (par exemple gnome-terminal tel qu'il est fourni par Red Hat 7.0, Helix Code/Ximian ou même Red Hat≥7.1) génèrent des séquences ASCII. En raison de cette dissonnance, les actuelles bases de données de terminal correspondent encore moins aux émulateurs de terminal qu'elles sont supposées décrire. Afin de donner un fondement solide aux explications qui suivent, nous supposons foncièrement corrects les paramètres proposés par la politique relative au clavier adoptée par Debian.

Lorsque l'on appuie sur une touche, un nombre de composants matériels et logiciels coopèrent afin de garantir que la signification de la touche que l'on a dans l'esprit (par exemple, d'émettre un certain caractère) concorde avec le comportement effectif de la touche. Je me concentrerai sur l'aspect logiciel (dans la mesure où notre contrôle sur le matériel est inexistant), et en particulier, provisoirement, sur les événements clavier liés à la sortie en console.

J'espère qu'au point où nous en sommes, le problème de base est clair : il y a un goulet d'étranglement entre le clavier et les applications console, à savoir, le fait qu'ils ne puissent communiquer que par séquences ASCII. Les touches spéciales sont ainsi d'abord traduites de touches symboliques en séquences, puis de séquences en capabilités de touche. Comme des consoles différentes ont des idées divergentes sur l'aspect que doit prendre cette traduction, nous avons besoin d'une base de données de terminal. Le système marcherait parfaitement, à un petit problème près : la base de données n'est pas toujours configurée correctement, et tout le monde ne l'utilise pas.

Les applications peuvent avoir un moyen de savoir quelle entrée de base de données utiliser : ce qui le rend réalisable, c'est une configuration adéquate de la variable d'environnement TERM. Dans certains cas, il y a une dissonnance entre l'émulateur de terminal et le contenu de l'entrée de la base de données suggérée par TERM.

En outre, de nombreuses applications n'utilisent pas la base de données de terminal (ou au moins pas entièrement), et considèrent les codes ASCII BS et DEL avec un sens qu'elles ne font que présumer : par conséquent, sans regarder dans la base de données, elles leur assignent une signification (en général, bien sûr, la signification est d'effacer le caractère situé avant ou sous le curseur). Ainsi notre beau schéma est complètement détruit (tout utilisateur de Linux en fait l'amère expérience). En l'occurrence, bash suppose que DEL doit faire un backward-delete-char, c'est-à-dire backspace.

Partant, tout fraîchement installé, il permet que la touche Backspace fonctionne en console comme on peut s'y attendre, mais uniquement à cause de la succession de deux renversements ! Bien sûr, la touche Suppr ne fonctionne pas. La cause de ce phénomène est que bash ne cherche pas dans la base de données de terminal la capabilité kdch1.

Juste pour illustrer la façon dont les choses se sont embrouillées, considérez le script fix_bs_and_del fourni avec la distribution Red Hat (et peut-être d'autres). Il assigne à la volée la touche symbolique BackSpace à la touche Backspace, et la touche symbolique Suppr à la touche Suppr. Désormais le shell fonctionne ! Malheureusement, tous les programmes qui se reposaient sur l'association correcte de la génération de touches symboliques et de mappages de la base de données de terminal ne marchent plus du tout maintenant, car la touche symbolique Suppr est mappée par la base de données terminfo vers DEL, et celui-ci vers la capabilité de touche kbs, de telle sorte que dans de tels programmes, les deux touches produisent un backspace.

Sous X, la situation n'est pas vraiment différente. Il y a juste une couche différente, à savoir que le système X Window traduit les scancodes en ses propres touches symboliques, qui sont bien plus variées et plus précises que celles de la console, et les fournit aux applications (au fait, c'est la raison pour laquelle XEmacs n'est pas tourmenté par ce problème : X traduit le code touche 22 par la touche symbolique BackSpace et le code touche 107 par la touche symbolique Suppr, puis l'utilisateur peut facilement assigner à ces touches symboliques le comportement désiré). Bien sûr, un programme d'émulation de terminal (en général un émulateur de VT100 dans le monde X) doit traduire les touches symboliques X en séquences ASCII, de telle sorte que nous en revenons à notre douloureuse affaire.

Plus précisément, en général xterm se comporte exactement comme la console (i.e. il émet les mêmes séquences ASCII), mais, par exemple, gnome-terminal dans la Red Hat <7.0 or ≥7.1 émet BS pour Backspace et DEL pour Suppr. Là où ça commence à devenir drôle, c'est quand vous vous rendez compte qu'ils utilisent par défaut la même entrée de base de donnée de terminal ; ainsi, le fait que la capabilité kbs soit associée à un DEL ASCII fait que toutes les applications qui se comportent correctement produisent le même comportement pour les touches Backspace et Suppr dans gnome-terminal. La simple commande

bash$ export TERM=gnome

peut résoudre le problème, dans ce cas, pour les applications qui se comportent correctement. Bon, pas toujours, parce qu'il pourrait manquer une entrée appelée gnome à votre système dans la base de données de terminal, en particulier s'il n'est pas parfaitement à jour.

Dans certains cas, ce n'est pas toujours une solution : si, par exemple, vous avez une distribution Red Hat 7.0, votre gnome-terminal se comporte comme une console. Mais attention : si vous avez mis à jour votre bureau en utilisant la distribution Helix, alors, votre gnome-terminal se comporte comme une Red Hat antérieure à la version 7.0.

À la seule fin de faciliter la compréhension de ce qui va suivre, appelons standard un émulateur de VT100 se comportant comme la console, et non-standard un qui émet BS pour Backspace et DEL pour Suppr^[3].

Ainsi, par exemple, xterm a toujours été standard dans la distribution Debian, tandis qu'il a oscillé à de nombreuses reprises entre les états standard et non-standard dans la Red Hat ; le comportement de gnome-terminal est encore plus erratique. Voir Section 8, « Plus de bidouillage » pour quelques renseignements sur la façon de rendre standard un terminal non-standard.

Lorsque vous écrivez une application en console, soyez gentils pour l'utilisateur et essayez de comprendre ce qui vient de l'entrée standard au moyen de la procédure de restauration suivante :

Remarquez encore que le problème qui égare souvent les gens qui essayent de régler leur système est qu'il règlent les choses au mauvais endroit. Puisque les parties qui fonctionnent ne fonctionnent souvent que par chance, essayer de régler le système en supposant que quelque chose est cassé mènera souvent à changer des paramètres corrects en paramètres incorrects.

void main(void) {int c; while(c = getchar()) printf("%d 0x%02X\n", c, c);}

6.2. Comment le faire

	Attention
	Ces réglages peuvent avoir quelques effets pervers. D'abord, ils ne marchent que pour les terminaux spécifiés. Ensuite, en théorie (mais il est peu probable que cela arrive) ils pourraient embrouiller la bibliothèque readline sur d'autres terminaux. Mais ces deux limitations sont en général sans inoffensives.

Tout d'abord, vérifiez avec infocmp gnome si vous avez déjà une entrée gnome dans votre base de données terminfo (nous réglerons plus tard le cas de termcap). Si l'entrée n'existe pas, la commande suivante

bash$ tic <(infocmp xterm |\
sed 's/xterm|/gnome|/' |\
sed 's/kbs=\\177,/kbs=^H,/' |\
sed 's/kdch1=\\E\[3~,/kdch1=\\177,/')

en créera une correcte dans ~/.terminfo. Si la même commande est lancée par l'administrateur, elle générera l'entrée dans la base de données globale (vous pouvez transgresser ce comportement en réglant TERMINFO sur ~/.terminfo). Notez que si votre entrée xterm est déjà non-standard (par exemple, vous avez une Red Hat ≤5.0), le script la copiera sans la changer, et c'est précisément ce que nous voulons.

Ajoutez maintenant le fragment suivant à ~/.inputrc^[4] :

"\e[3~": delete-char

Cette commande apprend à la bibliothèque readline comment gérer votre touche standard Suppr pour des émulateurs standards, et avec un peu de chance, cela ne devrait pas interférer avec d'autres terminaux. Cependant, nous devons maintenant expliquer à la bibliothèque la signification du caractère DEL dans les terminaux non-standards, en ajoutant par exemple

$if term=gnome
DEL: delete-char
Meta-DEL: kill-word
"\M-\C-?": kill-word
$endif

à ~/.inputrc. Si xterm est non-standard également, vous devez ajouter trois autres lignes pour lui. Inversement, si tous les terminaux sont standards, cette partie n'est pas requise. Toutes ces modifications peuvent être étendues en changeant le fichier /etc/inputrc.

Remarquez que les assignements conditionnels font que les terminaux non-standards fonctionnent pour autant que la variable TERM soit configurée correctement. Pour le garantir, il y a plusieurs techniques. D'abord, comme la valeur par défaut de la variable TERM est, pour gnome-terminal, xterm, si tous les terminaux sont standards, nous n'avons rien à faire. Si, cependant, un terminal qui utilise par défaut l'entrée xterm est non-standard, vous devez trouver un moyen de régler correctement la variable TERM ; supposez par exemple que ceci est vrai de gnome-terminal.

Le moyen le plus simple d'obtenir cet effet est de démarrer --termname=gnome, par exemple en réglant correctement la ligne de commande dans le lanceur de la barre d'outils GNOME. Si vous avez cependant une version plus ancienne et que cette méthode ne fonctionne pas, vous pouvez ajouter les lignes

if [ "$COLORTERM" = "gnome-terminal" ]
then
export TERM=gnome
fi

à votre fichier de configuration ~/.bashrc^[5]. L'assignement n'est exécuté que sous gnome-terminal, et règle correctement la variable TERM.

	Note
	Régler le terminal sur gnome pourrait empêcher ls d'utiliser des couleurs, car de nombreuses versions de ls ignorent que gnome-terminal supporte les couleurs. Afin d'éviter ce problème, créez un fichier de configuration ~/.dircolors avec dircolors --print-database >~/.dircolors, et ajoutez une ligne TERM=gnome au fichier de configuration.

Nous allons maintenant générer à la volée une entrée termcap qui convienne pour les émulateurs de terminaux non-standards ; on peut le faire comme suit, toujours dans ~/.bashrc :

if [ "$TERM" = "gnome" ]
then
export TERMCAP=$(infocmp -C gnome | grep -v '^#' | \
tr '\n\t' '  ' | sed 's/\\  //g' | sed s/::/:/g)
fi

Enfin, nous devons expliquer au périphérique de terminal quel caractère est généré par la touche d'effacement. Comme en général la touche d'effacement est supposée faire un retour arrière, il y a une astuce sympathique et efficace tirée du /etc/bashrc de Red Hat : ajoutez ceci à ~/.bashrc :

KBS=$(tput kbs)
if [ ${#KBS} -eq 1 ]; then stty erase $KBS; fi

C'est une idée toute simple : nous lisons la capabilité kbs à partir de la base de données de terminal, et réglons le caractère d'effacement sur sa valeur si c'est un caractère simple (ce qui est le cas aussi bien dans les terminaux standards que dans les non-standards).

	Note
	Certaines distributions peuvent avoir des réglages déjà en place dans le fichier de configuration /etc/inputrc, valable à l'échelle du système tout entier. Dans ce cas, vous pouvez éliminer les lignes redondantes de votre ~/.inputrc.

bindkey "^[[3~" delete-char

if ($?COLORTERM) then
   if ($COLORTERM == "gnome-terminal") then
  setenv TERM gnome
   endif
endif

if ($?TERM) then
   if ($TERM == "gnome") then
  setenv TERMCAP \
   "`infocmp -C gnome | grep -v '^#' | tr '\n\t' '  ' | sed 's/\\  //g' | sed s/::/:/g`"
  bindkey "^?" delete-char
  bindkey "^[^?" delete-word
  bindkey "\377" delete-word
   endif
endif

set KBS=`tput kbs`
if (${%KBS} == 1) then 
   stty erase $KBS
endif

La première chose à faire est de comprendre quels codes ASCII sont produits par une certaine touche utilisant le programme d'une ligne de C.

Une fois que vous savez quelles séquences sont produites, vous devez vérifier l'entrée terminfo en cours avec infocmp (ne soyez pas effrayé par la somme des informations affichées !) et assurez-vous que les capabilités kbs et kdch1 correspondent aux bonnes séquences (c'est-à-dire celles produites par les touches respectives). En outre, vous devez vérifier avec stty -a que le caractère d'effacement est celui qui est émis par la touche Backspace (remarquez que ^H représente BS tandis que ^? représente DEL).

S'il y a dissonnance, il peut y avoir plusieurs raisons : mauvais contenu de la variable TERM, mauvaise entrée de la base de données de terminal, mauvaise émulation de terminal sous X. J'espère qu'arrivé à ce point, vous avez suffisamment d'informations pour creuser la solution par vous-même.

Note

Si différentes applications se comportent différemment, il est possible que certaines d'entre elles utilisent correctement la base de données de terminal, et d'autres non. Rappelez-vous que le fait que les touches adoptent le bon comportement dans une application donnée ne signifie pas que l'application utilise correctement la base de données de terminal— elles peuvent ne fonctionner que par chance. Si vous voulez avoir une vérification indépendante, vous pouvez essayer de voir si l'éditeur ne fonctionne ou non. ne utilise toutes les capabilités du terminal, y compris kbs et kdch1, et n'utilise la signification désirée qu'en dernier recours.

Ainsi, vous n'êtes pas satisfait par toutes ces informations. Dans ce cas, vous pouvez faire encore plus de bidouillage sur la sortie de Backspace et de Suppr, en ayant recours aux commandes qui conviennent pour observer ou régler la façon dont X et la console traitent les touches.

Il peut arriver que, pour quelque raison, ce que j'ai dit sur X ne soit pas vrai, c'est-à-dire que X ne traduise pas le code touche 22 en touche symbolique BackSpace, ni le code touche 107 en touche symbolique Suppr (ou même que, sur votre clavier particulier, les codes touche associés à Backspace et Suppr ne soient pas 22 et 107). Afin de vous en assurer, vous devez utiliser xev, une application X simple qui affichera le code touche et la touche symbolique associés à la touche que vous enfoncez. Si quelque chose va de travers, il y a plusieurs façons de régler le problème : le moyen simple et provisoire est d'utiliser xmodmap, une commande qui vous permet de changer de nombreux réglages relatifs au traitement du clavier par X. Par exemple,

xmodmap -e "keycode 22 = BackSpace"
xmodmap -e "keycode 107 = Delete"

réglera correctement les touches symboliques (en supposant que 22 et 107 sont les codes touches corrects pour vous). Dans le cas où vous voudriez opérer quelques modifications sur le long terme, vous pouvez jouer avec les ressources vt100.backArrowKey, vt100.translations et ttyModes de xterm (et les applications de terminal similaires) dans le fichier de configuration ~/.Xdefaults. Une possibilité, par exemple, consiste en ceci :

XTerm.VT100.Translations: \
<Key>BackSpace: string(0x7F)\n\
<Key>Delete:string("\033[3~")

Vous devriez jeter un coup d'œil dans la page de manuel de xterm pour obtenir plus d'informations.

Le programme faisant pour la console ce que xev fait pour X est showkeys : il renverra les codes touche de console des touches que vous enfoncez. En combinant showkeys avec dumpkeys, qui affichera sur la sortie standard le mappage clavier de la console, vous pouvez facilement régler les dissonnances entre les codes touche et les touches symboliques. Parallèlement à xmodmap, loadkeys peut ensuite régler des associations isolées, ou charger des mappages clavier entièrement nouveaux. Avec cela, vous pouvez même changer la chaîne associée à une touche symbolique donnée. Si vous voulez enregistrer ces modifications, vous devrez définir un nouveau mappage clavier pour la console (vous devriez jeter un coup d'œil sur les mappages clavier du système, en général situés dans /lib/kbd).

Les réglages suggérés ici devraient résoudre une grande étendue de problèmes liés à l'effacement du texte que vous avez écrit (cependant, ils n'aident pas à en créer du nouveau :)).

Il y a un petit bug dans le réglage tout entier : si vous utilisez l'astuce du COLORTERM et que vous démarrez xterm depuis gnome-terminal, le premier verra TERM se régler sur gnome. Cet inconvénient est, bien sûr, en général complètement inoffensif, et n'a pas lieu si vous avez tout simplement démarré gnome-terminal avec un TERM convenablement réglé.

Un autre problème non trivial, et qui n'a pas vraiment de solution, est celui qui concerne la connexion à distance : si vous vous connectez sur un hôte dont la base de données de terminal est incohérente avec la vôtre, vous aurez à configurer les choses à la main.

Enfin, il faut observer que les réglages ne marcheront pas pour des applications cassées (par exemple, des applications ignorant la capabilité de touche kbs). Il n'y a pas grand chose à faire dans ce cas, car régler le problème d'une application cassée présente de fortes chances de casser toutes celles qui se comportent correctement.