uuoc, le mal absolu
J'ai été pendant longtemps membre de la liste Unix Haters, par ceux qui ont édité ce fameux livre. Quand je soutiens qu'Unix est vraiment une calamité, que 50 ans après son invention il n'y a aucune raison que cette chose existe encore tellement il lui manque de fonctionnalités de base, on me répond "ah, parce que tu trouves que Windows c'est mieux ?".
Ce n'est pas la question. Parce que oui, il faut savoir être critique vis à vis des outils que l'on utilise.
Mais au delà des problèmes intrinsèques d'Unix, il y a pas mal de problèmes qui se situent de l'autre coté de la chaise. Le plus commun est l'UUOC.
UUOC
Le UUOC, abbréviation de Useless Use Of Cat décrit l'utilisation abusive de l'utilitaire cat. Rappellons brièvement que cat sert à concatener des fichiers entre eux, ou parfois pour numéroter les lignes d'un fichier (cat -n) . Donc taper cat fichier est plutôt rare, vu que l'on concatène le fichier avec rien, c'est valable pour les fichiers courts (on utilisera more pour les plus long probablement).
Exemple typique d'UUOC : cat foo | grep bar ça c'est la base de l'ignominie. La syntaxe de grep est grep pattern fichiers donc : grep bar foo affiche bien les lignes contenant bar dans le fichier foo.
Voici un exemple tiré du manual, commande resolvconf :
Comment justifier le cat FILE ? Il suffit d'écrire resolvconf -a IFACE.prog < FILE
Les efforts nécessaires pour créer un nouveau processus
D'abord, il faut passer du mode utilisateur en mode noyau, c'est ce qu'on appelle un changement de contexte. Ça prend un temps fou, et ça nique le cache du processeur. Ensuite la création du nouveau processus implique de commencer par trouver le fichier executable sur le disque, et de vérifier les droits. Si tout va bien le noyaux les structures de données désignant un nouveau processus, et les initialize. On charge le code et les données statiques en mémoire, après avoir vérifier qu'on en a disponible, quelles pages il faudra utiliser, etc. (mettre à jour la table des pages, etc.). Bon, bref. quand tout ça est OK, on fait tourner le processus cat qui va refaire un appel système tout de suite pour ouvrir le fichier passé en argument, etc, etc. Bref, un temps de dingue.
Si la commande est commande < fichier le shell ouvre le fichier, fait des incantation magique pour qu'il prenne la place de stdin de la commande appellée, et enfin demande aux noyaux de créer un nouveau processus (commande).
Donc non, on ne peut pas dire que créer un nouveau processus ne coûte rien. Ça coûte un max, ça sollicite plein de choses, des entrées/sorites, configuration de la MMU, etc.
$ time for i in {1..50..1}; do cat /boot/kernel*img | grep foobar ; done >/dev/null
8.118 3.088 6.515
$ time for i in {1..50..1}; do grep foobar /boot/kernel*img ; done >/dev/null
6.769 0.832 5.946
Les différences, en temps passé -16,62% en temps processeur en mode utilisateur -73,06% et en temps dans le noyaux de -8.73%.
Le problème n'est pas seulement que l'on apprend pas aux nouveaux utilisateur d'unix, et du shell, qu'il ne faut pas commettre d'UUOC, mais que des dizaines d'exemples se retrouvent dans le manuel.
Quelques autres utilisations à proscrire
Une autre utilisation calamiteuse de cat est de l'utiliser avec more ou less. Ne rigolez pas, mais certains proposent de faire cat fichier | more au lieu de more fichier !
Pareil pour créer un fichier vide : cat > fichier suivi de ^d (control-d). Il est bien plus rapide de taper simplement > fichier.
Quelques utilisations un peu plus malines de cat
Ajouter une ligne en tête d'un fichier :
echo une ligne | cat - fichier
Ajouter un fichier entre deux commandes
(commande; cat fichier; commande)
Et évidement cat > fichier terminé par ^d (control d) si vous êtes dur de votre coup. Sinon, utilisez un éditeur, ed par exemple.
