J’ai souvent vanté la philosophie d’Unix, et comme le titre l’indique, je ne vais pas m’arrêter. Avant d’apprendre l’informatique, je pensais que tous les ordinateurs étaient impénétrables. Mais quand j’ai saisi Unix, à travers le médium imparfait de Linux, cela a eu un sens intuitif pour moi. A travers toute son évolution, Unix conserve en son cœur le charme que j’ai déjà remarqué.
Pour aborder un de ces traits qui est pertinent pour le point que je veux faire valoir, j’aime le fait que les outils les plus simples d’Unix sont aussi les plus polyvalents. En effet, ses créateurs pensaient qu’une poignée d’outils par défaut devrait permettre aux utilisateurs de faire tout ce qui est imaginable. À cette fin, les cerveaux-parents d’Unix ont également assuré une interopérabilité sans effort via l’interface commune des données textuelles. Tous ces choix de conception ont consciemment facilité la liberté de l’utilisateur.
Mais cela comporte une mise en garde importante : la liberté a des limites implicites raisonnables. Les philosophies ayant la vertu cardinale de libérer les adhérents ne peuvent jamais se permettre de se débarrasser de toutes les limitations pour le simple fait que les philosophies sans doctrines s’effacent d’elles-mêmes. Une philosophie, en existant, définit ce qu’elle est et délimite ainsi implicitement ce qu’elle n’est pas.
C’est ce que j’appelle le « paradoxe du taoïsme ». Sans devenir trop ésotérique, la philosophie taoïste soutient que tout se fait sans effort. L’existence est telle qu’elle doit être. En fait, sa nature est si globale qu’il est impossible de la définir. Alors, comment le taoïsme exprime-t-il cela si exprimer le taoïsme est impossible ?
Alors, où est-ce que je veux en venir, exactement ?
Unix vous permet délibérément d’aller dans la direction que vous voulez, oui, mais vous ne devriez pas vouloir aller dans certaines directions. En étudiant les innovations du secteur technologique, je vois des signes que les anciennes traditions s’estompent. Je ne suis pas du genre à sanctifier la tradition pour la tradition, mais je vois le mérite de maintenir une approche traditionnelle des tâches informatiques qui encourage la perspicacité.
Pour illustrer ce que je veux dire, voici quelques façons dont nous nous écartons de la voie Unix, et mon point de vue sur la raison pour laquelle nous devrions revenir sur la voie.
Utilisez les « chats » de manière responsable
La commande ‘cat’ est une affiche candidate pour les outils Unix élégamment simples. Il fait une chose, vider le contenu de tous les arguments passés, et le fait avec brio. Cependant, aussi utile que soit n’importe quel outil, il peut être surutilisé. Peu de commandes sont aussi gravement lésées par une utilisation excessive que « chat ». Il y a même un nom pour ça : usage inutile de chat (UUOC).
L’idée est que vous ne devriez pas utiliser ‘cat’ à chaque fois que vous devez opérer sur le contenu d’un fichier car de nombreux outils peuvent lire eux-mêmes le contenu du fichier. L’exemple le plus courant de ce faux pas est d’exécuter ‘cat’ sur un fichier, puis de le diriger vers ‘grep’ pour effectuer une recherche de modèle. Ceci n’est pas nécessaire car ‘grep’ peut déjà lire les fichiers : passez simplement le fichier comme argument supplémentaire après l’expression régulière. Vous devez donc opter pour la seconde de ces deux commandes plutôt que pour la première.
fichier chat $ | grep regex
$ grep fichier d’expression régulière
Pourquoi est-ce important ? Moins de commandes signifie moins de cycles CPU. Certes, cela n’a généralement pas d’importance, mais si vous tombez dans ce schéma, vous le paierez quand il le fera.
Plus important encore, la violation de l’UUOC enracine la mauvaise habitude de ne pas bien comprendre un outil avant de le combiner avec un autre. Si vous n’avez pas utilisé ‘grep’ pour lire le fichier, cela montre que vous n’avez pas bien appris ‘grep’.
Ce n’est pas un exercice académique. Dans un didacticiel pour un service Web largement déployé qui implique fréquemment la configuration de Linux, l’auteur demande aux utilisateurs de diriger ‘cat’ vers ‘grep’ de cette manière exacte. Pour les lecteurs qui ne connaissent pas mieux, ils ingèrent une mauvaise habitude sans la reconnaître comme telle.
Vérifiez la cible avant d’aller tuer
Les choses ne se passent pas toujours comme prévu. Plus les choses avancent, plus elles tournent mal. Qu’il suffise de dire que les ordinateurs ont beaucoup de choses à faire.
Les signaux d’arrêt Unix sont toujours l’étalon-or pour arrêter les programmes gelés dans leur élan. La commande principale qui transmet ces signaux, ‘kill’, n’est pas en cause, mais le ‘pkill’, terriblement pratique. Dans les meilleures pratiques Unix, on recherche l’ID de processus (PID) d’un programme, puis on le passe à ‘kill’. Par exemple, si votre navigateur est gelé, répertoriez vos processus avec la commande suivante et recherchez l’entrée de votre navigateur.
$ ps aux
Disons que le PID de votre navigateur est 5000. Nous le remettons ensuite à « tuer » et il exécute le hit.
$ tuer 5000
La façon la plus courante de le faire maintenant est de simplement donner le nom du programme à « pkill » et de le laisser déterminer qui désactiver.
$ pkill programme
Mais que se passe-t-il si vous saisissez mal le nom du programme ? Que se passe-t-il si un autre programme en cours d’exécution l’appelle (ou un programme contenant ce nom) ? Il est facile de tuer le mauvais processus en le spécifiant uniquement par son nom. Vous ne diriez pas à un facteur américain de livrer un colis à « John Smith », car qui sait où il finirait ? Vous ne devriez pas utiliser ‘pkill’ de cette façon pour la même raison.
Quand tout est ‘Sed’ et fait
Une autre pratique déroutante que j’ai vue en consultant ce même guide de service Web était celle de l’édition des fichiers de configuration à l’aide de « sed ». Je n’ai rien contre « sed ». Bien au contraire, c’est mon outil de prédilection pour la transformation de texte. Cependant, ce n’est pas quelque chose sur lequel s’appuyer pour la configuration du logiciel.
Je ne suis pas sur le point de dire avec une conviction à 100% que l’utilisation de « sed » pour modifier les configurations n’est pas Unix, mais ce n’est pas judicieux. Lors de la modification des fichiers de configuration, il est généralement plus sûr de le faire manuellement avec un éditeur de texte. Il y a plusieurs raisons à cela.
Tout d’abord, il vous est plus facile de revoir vos modifications, puisque vous êtes dans le fichier, les lignes modifiées sont visibles. Lorsque ‘sed’ s’exécute, il n’y a pas de sortie, vous ne pouvez donc pas vérifier immédiatement ce qui a changé.
Deuxièmement, les développeurs réorganisent occasionnellement le format des fichiers de configuration ou modifient les options activées et commentées par défaut dans les mises à jour logicielles d’un programme. Lorsque vous appliquez une commande ‘sed’ à un fichier de configuration, parce qu’elle spécifie ce qu’il faut trouver et par quoi le remplacer, vous faites des suppositions sur le contenu de ce fichier.
Je crains que l’utilisation habile de ‘sed’ ne devienne un art perdu car il ne semble pas toujours que les auteurs de didacticiels perçoivent pleinement les cas extrêmes possibles pour leurs commandes. Par exemple, je vois des tonnes de matériaux utiliser le drapeau « g » alors que ce n’est pas nécessairement approprié ou une bonne idée.
Pour donner les cours accélérés les plus cahoteux de ‘sed’, ‘sed’ nécessite une chaîne de script et du texte sur lequel opérer. Il y a beaucoup de choses que ‘sed’ peut faire, mais une utilisation courante est la recherche et le remplacement, ce qui est fait avec un script dans ce format.
sed ‘s/find_exp/replace_lit/’
Cela trouve chaque ligne avec l’expression régulière find_exp et remplace la première occurrence de cette expression dans la ligne par le littéral replace_lit.
L’ajout de « g » après la barre oblique finale indique à « sed » de remplacer toutes les occurrences de find_exp par replace_lit sur toute ligne contenant find_exp.
Les commandes d’édition de fichiers de configuration « sed » que j’ai vues utilisent le drapeau « g », malgré le fait que l’on ne souhaite pas modifier toutes les instances d’une ligne et qu’il ne faut pas supposer qu’il n’y a qu’une seule instance par ligne. Quand j’ai appris ‘sed’ pour la première fois, j’ai appris à ajouter « g » comme « juste la façon dont c’est fait », mais bien que je sache mieux maintenant, il n’y a aucun moyen que je sois le seul à intérioriser cette hypothèse erronée.
Garder la voie Unix de la voie Dodo
Si j’ai fait mon travail, j’espère vous avoir convaincu qu’au moins ces pratiques ne sont pas le produit d’une coutume lourde, mais une concentration intentionnelle sur des résultats optimaux. Aussi abstraite qu’elle puisse être parfois, la méthode Unix est la meilleure que je connaisse pour élever la maîtrise de ces systèmes, programmer l’efficacité ou appliquer pratiquement tous les principes de l’informatique.
Laisser un commentaire