Mind... - Tag - zsh

Encodage et terminal

Florent Bruneau — Sun, 02 Mar 2008 11:57:00 +0100

Beaucoup de personnes avec qui je discute sur IRC ont des problèmes avec l'encodage de leur terminal, de leur shell, de leur irssi, ou de tout autre logiciel en "ligne de commande". Comme j'en ai un peu marre d'expliquer la même chose toutes les semaines, voici une petite mise au point sur les réglages à faire pour travailler efficacement en ligne de commande.

Introduction

Le point le plus important à mémoriser est que pour avoir une console avec un encodage spécifique il faut que plusieurs couches de logiciels utilisent le même encodage. Prenons le cas simple où nous avons un shell dans un terminal.

Le terminal est un logiciel qui ne fait que convertir les entrées de l'utilisateur vers des entrées compréhensibles par le logiciel qu'il fait tourner, et qui interprète la sortie de ce logiciel pour qu'elle soit lisible par l'utilisateur. Donc pour que le terminal affiche correctement ce qu'indique le shell, il faut qu'il utilise le même encodage que celui-ci. Si par exemple mon shell écrit de l'UTF-8 alors que mon terminal attend du latin1, les caractères multi-octets de l'UTF-8 seront mal interprétés et afficheront un caractère par octet. Ainsi un "é" en utf8 s'affiche comme un "Ã©" en latin1.

Pour l'entrée de l'utilisateur, c'est la même chose. Si mon terminal est en latin1 et mon shell en utf8, si j'entre un "é" dans mon terminal, celui-ci sera passé à mon terminal comme un seul octet (de valeur 0xE9). Or mon shell attend de l'utf8 et lorsqu'il reçoit un 0xE9, il considère que je viens d'entrer un octet d'un caractère multi-octets... les prochains caractères que j'entrerais seront donc ajoutés à mon 0xE9 jusqu'à ce que mon shell considère que j'ai entré un caractère... assez embêtant.

Il faut donc faire extrêmement attention à choisir un encodage unique compatible avec son shell et son terminal (et les logiciels qu'on compte utiliser).

Terminal

Le réglage du terminal dépend exclusivement du logiciel en question. Certains terminaux permettent de choisir son encodage, d'autres non. Cela peut donc être un bon critère pour choisir son logiciel. Pour utiliser l'UTF-8, vous pouvez prendre Konsole, urxvt, le Terminal de Mac OS X...

Shell

Le réglage du shell se fait par des variables d'environnement qu'on appelle couramment les "locales". Le réglage courant est accessible en tapant "locale" dans le shell. Un certain nombre de variables sont concernées :

gestion de la langue du shell (et des programmes liés)
gestion des formats (dates, monnaies, virgules...)
LC_ALL est un "fallback" (l'encodage par défaut si aucun autre n'a été défini pour une variable donnée).

Chaque variable est de la forme xx_YY.ZZ. xx_YY défini la zone géographique et la langue (fr_FR pour le français, en_US pour l'anglais-US). ZZ défini l'encodage. Il est important que toutes les variables utilisent le même encodage (mais elles peuvent avoir des langues différentes). Pour faire de l'UTF-8 pur, un bon choix est d'exporter LC_ALL="en_US.UTF-8" dans la configuration du shell (ou fr_FR.UTF-8 pour ceux qui veulent un shell en français).

Il faut par contre faire attention, l'UTF-8 n'est pas supporté par tous les shells (à partir de 4.3 pour zsh par exemple).

Irssi

Pour irssi, il y a un point supplémentaire à prendre en compte : l'encodage du réseau. Ainsi si j'ai un channel en latin1 à afficher en utf8 (et sur lequel je veux poster). Il faut donc que irssi fasse de transcodage à la volée... et bien sûr il faut lui dire ce qu'il faut faire.

Tout d'abord il faut lui indiquer l'encodage du terminal. Pour ceci il y a la variable term_charset :

settings = {
  "fe-common/core" = {
    term_charset = "UTF-8";
  };
};

Ensuite, il faut indiquer pour chaque réseau (ou channel) l'encodage du réseau. Ce n'est en fait nécessaire que si l'encodage est différent de celui du terminal, mais ça ne coûte rien de le spécifier pour chaque réseau. Ainsi je suis sur RezoSup (qui est en latin1) et sur FreeNode (qui est en utf8), il me suffit d'ajouter :

settings = {
  core = {
    recode = "yes";
  };
};
conversions = { 
  FreeNode = "UTF-8";
  Rezosup = "ISO-8859-1";
};

Les entrées "FreeNode" et "Rezosup" doivent reprendre le nom du chatnet donné dans la section "servers" de la configuration. Pour spécifier l'encodage spécifique à un channel, il suffit de mettre "Chatnet/#channel" = "encoding";

Compter les fichiers

Florent Bruneau — Thu, 30 Aug 2007 23:12:00 +0200

C'est un peu la suite de mon post "Outils pratiques" où je donnais deux scripts permettant de rendre les commandes SVN plus conviviales. Encore une fois, je réinvente sans doute la roue (des outils équivalents doivent déjà exister... sans doute en mieux), mais je pense que chercher ce genre d'outils sur internet m'aurait pris plus de temps que ce qu'il m'a fallu pour le développer.

En ce moment je manipule des fichiers, beaucoup de fichiers (et même, beaucoup de gros fichiers), que j'ouvre, rouvre, et ferme et puis referme. Et à force d'ouvrir, on oublie parfois de refermer, et là, c'est comme une fuite de mémoire, sauf que le nombre limite de fichiers ouverts est beaucoup plus rapidement atteinte que la limite de mémoire... dans la configuration de base sur un linux, un programme n'a le droit qu'à 1024 descripteurs de fichiers. D'où mon problème : comment traquer les "file-handle leaks" ?

Pour le faire, je me suis fait rapidement un petit script qui permet d'analyser les données issues d'un strace. strace est, pour ceux qui ne le savent pas, un programme très pratique qui permet de lister les appels systèmes. Dans mon cas présents, surveiller les ouvertures fermetures de fichiers revient à traquer les commandes open (ouverture d'un fichier), et les commandes close. Donc, je récupère simplement la liste des appels à open et close :

[bash]
strace -f -e trace=open,close mon programme 2> /quelque/part

Et ainsi, le fichier /quelque/part contient la liste complète des appels à open et close effectués par mon programme (et ses processus fils). Il ne reste plus alors qu'à analyser le contenu de /quelque/part. Pour ceci, il suffit de peu de lignes de code (en perl pour ma part, mais d'autres auraient fait la même chose en shell, python... ou n'importe quel langage de scripting) :

[perl]
#!/usr/bin/perl 
 
my %files; 
my %modes; 
my %lines; 
 
my $lineNb = 0; 
my $maxOpened = 0; 
my $currentOpened = 0; 
my $totalOpened = 0; 
 
for $line (<STDIN>) { 
  if ($line =~ /open\\("([^""]+)", ([^\\)]+)\\)\\s*=\\s*(\\d+)/) { 
    $files{$3} = $1; 
    $modes{$3} = $2; 
    $lines{$3} = $lineNb; 
    $totalOpened++; 
    $currentOpened++; 
    if ($currentOpened > $maxOpened) { 
      $maxOpened = $currentOpened; 
    } 
  } 
  if ($line =~ /close\\((\\d+)\\)/ && $files{$1} ne '') { 
    $files{$1} = ''; 
    $currentOpened--; 
  } 
  $lineNb++; 
} 
 
print "$totalOpened files opened, max. $maxOpened at the same time
"; 
print "$currentOpened files not closed
"; 
for $id (keys %files) { 
  local $file = $files{$id}; 
  local $mode = $modes{$id}; 
  local $line = $lines{$id}; 
 
  if ($file ne '') { 
    print "[line $line] id=$id, open $file with mode $mode
"; 
  } 
}

Pour simplifier le tout, on rajoute une fonction dans le zshrc pour wrapper tout ça, et ça donne (attention, ceci ne fonctionne que sous linux, mktemp n'a pas la même syntaxe sur MacOS, et surtout, strace n'est pas disponible sur Mac

[bash]
function checkFiles() { 
  TEMPFILE=`mktemp` 
  strace -f -e trace=open,close $* 2> $TEMPFILE 
  cat $TEMPFILE | ~/.zsh/trackFiles.pl 
  rm $TEMPFILE 
}

Avec, ça, il ne me répond :

% checkFiles cp test test2
12 files opened, max. 2 at the same time
0 files not closed

Si maintenant, je fais un programme minimaliste qui oublie de fermer un fichier :

[c]
#include <stdio.h> 
 
int main() { 
  FILE* file = fopen("test", "r"); 
  return file != NULL ? 0 : 1; 
}

% gcc test.c -o tester
% checkFiles ./tester
3 files opened, max. 1 at the same time
1 files not closed
[line 4] id=3, open test with mode O_RDONLY

Voilà, maintenant je sais que mon programme oublie de fermer un fichier, que ce fichier s'appelle "test", et qu'il est ouvert en read-only. La ligne "4" est la ligne dans la sortie de strace, et n'a aucun rapport avec la ligne 4 du fichier source (contrairement aux apparences).

Outils pratiques

Florent Bruneau — Tue, 13 Mar 2007 19:21:00 +0100

Etant donné que je travaille énormément avec SVN. C'est un outils très addictif... à tel point que je l'utilise dès que je travaille sur un projet (seul ou à plusieurs), je crée un reposoire pour le projet (c'est un excellent moyen de ne pas perdre son travail suite à une fausse manoeuvre). Comme en plus je ne supporte pas les front-end pour SVN, je travaille toujours en ligne de commandes...

Pour pouvoir améliorer la sortie des commandes SVN dans mes consoles, j'ai fait surchargé la commande svn par une fonction zsh :

[bash]
function svn() {
    if [[ $1 == "ci" || $1 == "commit" || $1 == "propedit" || $1 == "propset" || $1 == "help" ]]; then
        /usr/local/bin/svn $*
    elif [[ $1 == "preci" || $1 == "precommit" ]]; then
        /usr/local/bin/svn status | grep -v '?' | ~/.zsh/zshcolorsvn
    else
        /usr/local/bin/svn $* | ~/.zsh/zshcolorsvn
    fi
}

Cette fonction est donc très simple :

si la commande nécessite un interaction de l'utilisateur, on appel directement le programme svn (le cas de help permet de ne pas casser la tab-completion de zsh)
sinon on envoi la sortie de svn dans un script qui réalise sa coloration syntaxique

Ceci donne un résultat de la forme suivante :

C'est donc extrêmement pratique ; ça permet de distinguer facilement les modifications, ça permet aussi de voir d'un seul coup d'oeil les conflits et la liste des fichiers modifiés. En plus ça fonctionne également avec des commandes comme cvs ou diff :

[bash]
# SVN
function svn() {
    if [[ $1 == "ci" || $1 == "commit" || $1 == "propedit" || $1 == "propset" || $1 == "help" ]]; then
        /usr/local/bin/svn $*
    elif [[ $1 == "preci" || $1 == "precommit" ]]; then
        /usr/local/bin/svn status | grep -v '?' | ~/.zsh/zshcolorsvn
    else
        /usr/local/bin/svn $* | ~/.zsh/zshcolorsvn
    fi; fi
}

# SVN avec conversion de la sortie en latin1
function svn_utf8() {
    if [[ $1 == "ci" || $1 == "commit" ]]; then
        svn $*
    else
        svn $* | iconv -f utf8 -t iso-8859-1
    fi
}

function cvs() {
    if [[ $1 == "diff" ]]; then
        shift 1
        /usr/bin/cvs diff -ubN $* 2> /dev/null | ~/.zsh/zshcolorsvn
    elif [[ $1 == "ci" || $1 == "commit" || $1 == "propedit" || $1 == "propset" || $1 == "help" ]]; then
        /usr/bin/cvs $*
    else
        /usr/bin/cvs $* 2> /dev/null | ~/.zsh/zshcolorsvn
    fi;
}

function diff() { /usr/bin/diff -u $* | ~/.zsh/zshcolordiff }

Les scripts nécessaires sont disponibles : zshcolorsvn et zshcolordiff

Seul défaut : pour pouvoir utiliser les commandes sans coloration... il faut taper chemin complet.