vim and screen 256 colors - MacOS X Snow Leopard

Nature du problème

Je souhaite utiliser des thèmes 256 couleurs avec Vim et plus spécifiquement le thème railscasts que j'utilisais sous Linux (thème d'origine TextMate utilisé par Ryan Bates pour ses screencasts). Vim et iTerm sont capables d'utiliser des thèmes 256 couleurs. Concernant iTerm, il suffit de choisir 'xterm-256color' dans la section 'Terminal Profiles'. Quant à Vim, il suffit d'ajouter set t_Co=256 à son .vimrc.

Attention, le Terminal livré avec Leopard ne supporte toujours pas un mode 256 couleurs. De toute façon, vous avez tout à gagner à passer à iTerm si ce n'est pas déjà fait (full screen, profiles à gogo suivant l'activité, etc...)

Le réel problème vient de la version de screen livrée avec Leopard qui ne supporte pas le mode 256 couleurs. Evidemment, comme j'utilise à outrance 'screen', c'est plus qu'ennuyeux de se retrouver avec un Vim en mode dégradé (surtout lorsqu'on épluche du code Rails à gogo comme c'est mon cas depuis plus d'une semaine). J'ai donc craqué et pris le temps de recompiler 'screen' avec le support du mode 256 couleurs.

Choix des sources

A défaut de faire correctement son boulot pour les utilitaires et logiciels en ligne de commande, Apple propose, sans doute pour se faire pardonner, des pages sur les logiciels Open Source utilisés pour le Mac. Je suis donc parti des sources de 'screen' pour Mac OS X version 10.6.4.

Je récupère également les sources du 'screen' correspondant à la version '10.6.2' car il manque 3 patches à la version '10.6.4' pour qu'on puisse le compiler correctement en ligne de commande. Les autres patches sont inutiles car les fichiers précédemment concernés ont déjà été modifiés (ils sont __APPLE__ powered ^^).

Lignes de commande en mode Canal+

J'ai choisi d'utiliser des commandes qui paraitront un peu 'cryptées' pour la plupart. Compiler un programme n'a rien de passionnant, alors autant apporter un peu de fun 'bash' pour le faire. Il suffit de copier les lignes qui suivent en respectant l'ordre et sans rien taper de plus entre chaque commande pour que ça se passe parfaitement (copier-coller roxe des mamans ours). Une ligne est fortement exagérée (celle du 'cd') et j'avoue que je ne l'aurais jamais tapée si ce n'était pour l'exemple et par nostalgie (cette ligne me rappelle la belle époque du Obfuscated Perl Contest).

Compilation et installation de 'screen'

cd
mkdir -p src/tarball && cd !#:2:h
wget http://www.opensource.apple.com/tarballs/screen/screen-19.tar.gz -O tarball/!#:^:t
wget !*:gs/9/6
tar xvzf !$:gs/6/9
mkdir !$:t:r:r/patches
tar xvzf !w:$ -C !$ --strip-components=2 *.diff
cd !mk:$:h/!#:$:h:gs/-19/
patch -p0 < ../patches/Makefile.in.diff
patch -p0 < ../patches/config.h.in.diff
patch -p0 < ../patches/configure.diff
./configure --enable-locale --enable-telnet --enable-colors256 --enable-rxvt_osc --prefix=/usr/local --disable-dependency-tracing
make
sudo make install

Modification du .screenrc

Il suffit d'ajouter ces lignes à son .screenrc (comme indiqué dans l'en-tête de railscasts.vim)

attrcolor b ".I"
termcapinfo xterm-color 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
defbce "on"
term screen-256color-bce

où xterm-color doit correspondre à la réponse de echo $TERM

Utiliser son nouveau 'screen'

Je ne préfère pas toucher à l'installation d'Apple car je n'ai pas envie qu'une prochaine mise à jour vienne me compliquer la vie ^^. Pour utiliser des programmes recompilés (et donc, déjà existants sur le système), j'opte généralement pour l'utilisation de mon ~/bin. Il n'existe pas par défaut, il faut donc le créer si vous ne l'avez pas déjà fait.

mkdir ~/bin

Depuis son ~/bin, on fait simplement un lien vers son 'screen'.

ln -s /usr/local/bin/screen-4.0.3 screen

Si ce n'est pas déjà fait, on ajoute enfin son ~/bin à son PATH (dans son .bashrc ou son .bash_profile) en s'assurant qu'il sera bien le premier à être interrogé.

if [ -d ~/bin ]; then
    export PATH=~/bin:$PATH
fi

which screen doit vous dire que le système utilisera bien le screen nouvellement installé.

That's all.

Peu utilisé mais tellement élégant

Lorsqu'on sait que :

echo a{b,c,d}e

retourne

abe ace ade

Il est bien plus élégant et bien plus rapide d'écrire :

cp .vimrc{,.bak}

que

cp .vimrc .vimrc.bak

ou

mkdir -p foo1/foo2/{src,examples,app}

que

mkdir -p foo1/foo2/src
mkdir foo1/foo2/examples
mkdir foo1/foo2/app

pipe, fifo & ssh

L'espace de stockage d'un serveur ne permet plus de faire une archive car le cumul de la taille du tarball et des données existantes sur le serveur représente plus que l'espace disponible.

Dans ces conditions, comment effectuer un transfert ou une copie des données sur un autre serveur ?

Un pipe utilisé via ssh va venir à notre secours (FULL est le serveur plein, /srv le répertoire à sauvegarder et EMPTY le serveur qui récupère l'archive).

Depuis FULL :

# mkfifo /tmp/fifo
# tar czf /tmp/fifo /srv

La dernière commande entrée est bloquante. FULL attend qu'on lise la fifo.

Depuis EMPTY, on va aller lire la fifo pour récupérer le contenu du tarball :

# ssh -e none FULL cat /tmp/fifo > mon_tarball.tgz

.inputrc

Pour faire une recherche dans le .bash_history, CTRL+R est disponible par défaut.

En complément, il est possible d'effectuer une recherche sur le début de la commande avec les flèches haut et bas après avoir rajouté 2 lignes à son .inputrc (ou dans le /etc/inputrc pour la mise à disposition de tous les utilisateurs) :

# Déplacement dans l'historique en utilisant les flèches bas et haut
"\e[A": history-search-backward
"\e[B": history-search-forward

et quitte à modifier son inputrc :
# Les beeps me saoulent
set bell-style visible
# Par pitié, 1 seul TAB pour le complètement !
set show-all-if-ambiguous on

.bash_profile sous X (Debian Etch)

Lorsqu'on est habitué à ranger ses scripts dans ~/bin, sous X, on peut être étonné que ces fichiers ne soient pas dans le PATH alors que le ~/.bash_profile y fait référence :

# set PATH so it includes user's private bin if it exists
if [ -d ~/bin ] ; then
PATH=~/bin:"${PATH}"
fi

C'est tout simplement que le ~/.bash_profile est dédié au mode console et qu'il n'est pas lu lors d'une connexion sous X.

Pour y remédier, il suffit de créer un fichier dans /etc/X11/Xsession.d/. Par exemple, on peut créer un fichier 70bash_profile dont le contenu sera :

if [ -f ${HOME}/.bash_profile ]; then
. ${HOME}/.bash_profile
fi

Ainsi, lors de la prochaine connexion sous X, le ~/bin sera rajouté au PATH et les scripts seront directement accessibles.

bash prompt color pour screen (Debian Etch)

Quand on passe sa vie dans des consoles, il est préférable de repérer visuellement si on est dans un terminal screen ou non.

Une méthode consiste à changer la forme du prompt. A titre d'exemple, on peut paramétrer le prompt de l'utilisateur courant pour qu'il soit de couleur cyan et celui de root rouge. Lorsqu'on entre dans un terminal screen, on peut par exemple passer le prompt en gras pour indiquer qu'on est dans un screen. Cela ne choque pas et permet de savoir immédiatement s'il s'agit d'un screen lorsqu'on passe en revue les terminaux ouverts.

Il faut modifier le .bashrc par défaut de l'utilisateur (et le /etc/skel/.bashrc si vous créez régulièrement des utilisateurs) en rajoutant 2 sections pour le « case "$TERM" » :

xterm*|rxvt*)
PS1='${debian_chroot:+($debian_chroot)}\e[0;36m\u@\h:\e[0;37m\w\e[0;36m\$\e[0;37m '
;;
screen)
PS1='${debian_chroot:+($debian_chroot)}\e[1;36m\u@\h:\e[1;37m\w\e[1;36m\$\e[0;37m '
;;

Pour root, on rajoute la section :

case "$TERM" in
screen)
PS1='\e[1;31m\u@\h:\e[1;37m\w\e[1;31m\$\e[0;37m '
;;
xterm*|rxvt*)
PS1='\e[0;31m\u@\h:\e[0;37m\w\e[0;31m\$\e[0;37m '
;;
*)
PS1='\h:\w\$ '
;;
esac