Les entrailles de GNU Screen (que j'abrègerai en screen par la suite) sont parfois difficiles à comprendre. L'histoire commence ainsi : je possède une machine NetBSD, un peu bruyante, que j'allume le matin au lever et que j'éteins le soir au coucher. J'utilise screen sur cette machine, et j'aimerais, par grosse fénéantise, que ce dernier se lance au démarrage de ma machine, en mode détaché. De la sorte, il ne me reste qu'à lancer un bon vieux “screen -r” lorsque que je m'y connecte et mon comportement ne change pas d'autres machines allumées 24h/24 : je me connecte, je “screen -r” et je suis prêt.

Jusque-là rien de bien particulier : un petit tour dans la page de manuel m'apprend que cela est déjà possible :

screen -d -m

Cette commande permet de faire en sorte qu'il démarre en mode détaché, et que c'est justement fait pour un éventuel script de démarrage. En bref, la paix dans le monde, mes amis :-)

Je me précipite donc sur \${EDITOR} et entame l'écriture épique d'un script shell qui va lancer screen en mode détaché sous l'identité de l'utilisateur que je suis, avec le fichier .screenrc qui convient. Le script fonctionne, le script fonctionne au démarrage de la machine (c'est mieux, hein ?), toujours la paix dans le monde, avec les oiseaux qui chantent, nous sommes dans un rêve :-)

Donc, plein d'illusions, je lance la commande screen -r . Et là, c'est le drame : le prompt de mon shell (bash) n'est pas coloré, et n'affiche pas le répertoire courant. Après avoir demandé conseil à mon moteur de recherche favori, je me rend compte que dans ce cas, screen a eu la bonne idée de remplacer la variable d'environnement PS1 (qui définit le prompt) par une valeur autre. D'où vient-elle ? Je ne le savais pas encore. J'ai essayé de redéfinir cette variable dans mon fichier de configuration .screenrc, sans succès. En désespoir de cause, je tente un “unset PS1”. Victoire ! J'ai mon prompt personnalisé ! je suis joie, bonheur, les oiseaux chantent, la paix dans le monde, tout ça tout ça...

Jusqu'à ce que j'édite un fichier texte. Et là, c'est le drame (à nouveau) : mon éditeur de texte, VIm, dispose d'une fonction de coloration syntaxique que j'active par défaut. C'est trèèèès pratique. J'active aussi la numérotation des lignes. Mais là, pas de couleur. Il s'agit pourtant d'un type de fichier connu. Je tente ma chance avec d'autres programmes disposant d'un affichage coloré, sans succès non plus. Après quelques bidouillages, je me rend compte qu'en changeant la variable d'environnement TERM de screen à xterm-color, j'obtiens à nouveau la couleur. En désespoir de cause j'ajoute “export TERM=xterm-color” au fichier /usr/pkg/etc/bashrc (ce qui m'évite de copier-coller un .bashrc dans le \$HOME de mon utilisateur et de root), je relance le script et là : couleur :-)

Avec le recul de l'écriture de ce billet, je me suis rendu compte que lorsque j'utilise screen -d -m, ce dernier charge mon fichier .profile (qui charge .shrc). Ces deux fichiers m'ont posé problème dans le passé : par exemple .profile contient deux exports qui entrent conflit avec mon bashrc, “export EDITOR=vi” et “export PAGER=more” (j'utilise vim et most à la place). J'ai aussi remarqué la ligne suivante dans le fichier .shrc :

export PS1="$(whoami)@$(hostname -s)$ "

Tiens, c'est marrant, c'est exactement le prompt que j'avais lors de mon premier problème... ;-)

Bref, ma solution n'est peut-être pas la plus élégante, mais au moins ça fonctionne. Mais comme on me l'a fait remarquer il y a presque deux mois, sur les systèmes Unix : There Is More Than One Way To Do It (Il y a plus d'une façon de le faire).

Commentaires

Le 28/11/2011 10:50 par Natacha

Il y a plus d'une façon de faire, mais parfois certaines sont plus justes que d'autres… En l'occurrence, tricher sur le TERM risque de venir tout un jeu d'ennuis : tu fais croire aux applications qu'il faut utiliser les séquences d'échappement d'xterm-color alors que tu es dans screen, et les deux ne sont pas interchangeables.

Par exemple d'après le termcap que j'ai sous les yeux, screen envoit \033[4~ pour signaler à l'application que la touche Fin a été utilisée, chose que l'application ne va pas comprendre parce que xterm-color evoits \033OF. Donc je soupçonne que ce changement de TERM casse la touche Fin. Et dans l'autre sens, la séquence à envoyer à screen pour effacer l'écran est \033[H\033[J mais l'application qui croit qu'elle a affaire à un xterm enverra \033[H\033[2J à la place.

Si ça ne te poses pas de problème, tant mieux, mais ça fait une piste pour toutes les petites choses qui vont casser comme ça ;-)

Le 28/11/2011 21:55 par Nils

Ça ne me pose pas de problème pour le moment, surtout que je n'utilise pas souvent la touche Fin. Mais cela me forcera à trouver un moyen plus élégant et à écrire un autre billet :)