Archélogie des commandes POSIX (rédaction en cours)

• Les commandes
  • admin, delta, get, prs, rmdel, sact, sccs, unget, val, what
  • ar
  • asa
  • at
  • batch
  • cflow
  • cksum
  • comm
  • ed
  • ctags

CET ARTICLE EST EN COURS DE REDACTION, IL EST PUBLIÉ EN AVANCE POUR FACILITER L’ÉCHANGE AVEC DES PERSONNES SUSCEPTIBLES DE POUVOIR L’AMÉLIORER.

En 2024 est sorti une nouvelle version de POSIX nommée POSIX 2024. C’est l’occasion parfaite de (re)découvrir la liste des commandes spécifiées dans son volume XCU, décrivant le shell et les commandes associées. Pour les nouveautés de cette version 2024 je vous renvoie vers ce super article malheureusement tout en anglais.

Dans la traduction française des principes du perma-computing trouvable sur le site de Timothée Goguely on peut lire :

Il est bon d’expérimenter de nouvelles idées, de nouveaux concepts et de nouveaux langages, mais en dépendre est généralement une mauvaise idée. Appréciez les technologies matures, les idées claires et les théories bien comprises lorsque vous construisez quelque chose qui est destiné à durer.

• Vous pouvez aussi lire cela comme « faites pousser vos racines sur un sol solide ». Apprenez des choses qui durent, enrichissez votre tradition locale, connaissez l’histoire de chaque chose.

Pour chaque commande je vais donc tenter, dans la limite de ce que je trouve publiquement sur internet et dans les cerveaux autour de moi, de comprendre son utilité, son histoire et les raisons de son éventuelle désuétude. Je remercie les contributeurices à wikipedia que je vais évidemment largement plagier.

Évidemment ce que constitue une commande “obscure” ne sera pas identique pour moi ou pour vous. Les critères que j’ai utilisé pour intégrer une commande à cet article ou pas sont strictement personnels. Par exemple, j’y ajoute volontairement des commandes en réalité assez connues simplement parce que je les aime bien et je pense qu’elles gagneraient à l’être encore plus !

La liste, surtout dans sa première version, ne sera pas complète. Si vous avez des informations supplémentaires ou des corrections à y apporter n’hésitez pas à me contacter. Je n’étais pas vivant ou ne pratiquait pas l’informatique durant la création et/ou l’usage de ces commandes donc il y en aura forcément.

L’immense majorité des sources que je vais citer son anglais et je ne vais pas systématiquement les traduire.

Les commandes

La liste complète

Je les prends par ordre alphabétique.

admin, delta, get, prs, rmdel, sact, sccs, unget, val, what

Fin 1972 le “Source Code Control System” (SCCS) est développé pour versionner le code d’un IBM System/370. Il est ensuite réécrit en C pour être utilisé sous Unix.¹ Avec l’avènement de nouveaux logiciels de versionnages SCCS semble être tombé en désuétude². Son histoire commune avec Unix offre une place de choix à ses commandes.

L’usage était d’utiliser la commande sccs comme “frontend” pour les autres. Par exemple

sccs -d /x -p y get a/b

devient

get /x/a/y/s.b

En plus des commandes implémentées indépendamment de sccs, il en existe tout un tas implémenté en tant que “built-in” de sccs³.

ar

ar est utilisé pour créer des archives. Aujourd’hui on utiliserait plutôt tar.ar précède tar de 8 ans. ar reste utilisé pour créer des bibliothèques statiques au format .a, l’idée étant de combiner tout ses fichiers objets .o en une seule archive plus facile à invoquer à la compilation. Il est également utilisé pour créer les paquets debian .deb dans lesquels on retrouve tout de même deux archives .tar⁴.

Pourquoi ar n’est plus utilisé pour faire des archives en dehors de ces deux cas ? J’ai trouvé quatre raisons :

1. Possiblement du fait d’un manque de standardisation du format, comme écrit dans la norme POSIX⁵ :

The archive format is not described. It is recognized that there are several known ar formats, which are not compatible. The ar utility is included, however, to allow creation of archives that are intended for use only on one machine.

A l’inverse tar venait avec un format spécifié et ouvert, permettant à l’outil d’être implémenté plus facilement et à différentes implémentations d’être compatibles.

2. ar ne conserve pas l’arborescence de fichiers, les droits d’exécutions etc

Si l’on a

/tmp/test
├── A
│   └── bidule
└── truc

que l’on ajoute ces fichiers à une archive en faisant

$ ar rcs test.ar /tmp/test/A/bidule /tmp/test/truc

puis que l’on extrait les fichiers de l’archive ailleurs :

$ ar x test.ar
$ tree
/tmp/test2
├── bidule
├── test.ar
└── truc

On ne retrouve pas notre dossier A. Si truc avait été un exécutable, il ne le serait plus une fois décompressé non plus.

3. tar, c’est à dire “Tape archive” gère mieux l’écriture sur bande

Je ne suis pas certain de bien comprendre les détails mais il semblerait que tar permet de faciliter l’écriture sur bande⁶.

4. La structure des archives ar permet aux routines contenues dans des fichiers objets de s’appeller rapidement entre elles

D’après le manuel :

ar creates an index to the symbols defined in relocatable object modules in the archive when you specify the modifier s. Once created, this index is updated in the archive whenever ar makes a change to its contents (save for the q update operation). An archive with such an index speeds up linking to the library, and allows routines in the library to call each other without regard to their placement in the archive.

Comme pour l’histoire des bandes je ne comprends pas les détails mais il semblerait que tar fonctionne suffisament différement pour que les tarballs ne puissent pas être utilisés de cette façon.

Après ces recherches je réalise que l’association immédiate que je fais entre le concept d’archive numérique et les outils tels que tar, zip, 7zip m’a rendu plus confus que je n’aurais du l’être. Le type d’archive créé par ar a été pensé pour faire des bibliothèques et, même si il peut dans une certaine mesure être utilisé comme celui de tar, ils ne devraient pas être considérés comme concurrents.

Cette réponse de “Clifford” sur Stack Overflow indique que sur d’autres systèmes l’utilitaire permettant de créer ce type d’archive est nommé “librarian”⁷, faisant donc spécfiquement référence à son usage principal. Je n’ai pas vérifié cette affirmation.

Cette réponse de Steve Kirkendall sur le newsgroup comp.os.linux.misc résume bien tout ce que j’ai dit et termine sur :

So that’s basically it. Tar archives are more portable, more resiliant when damage occurs, and can handle odd block sizes. Ar archives are easier to access and more compact.

En français :

Les archives tar sont plus portables, plus résilientes aux erreurs et peuvent gérer des tailles de blocs différents. Les archives Ar sont plus faciles d’accès et plus compactes.

asa

Avant l’avènement des terminaux avec écran, l’interaction avec les ordinateurs se faisait via des téléscripteurs⁸.

Ces téléscripteurs étaient munis (ou couplés avec ?) d’imprimantes permettant d’inscrire sur papier la sortie d’une commande. Afin de contrôler le comportement du chariot de l’imprimante et le mouvement du papier des caractères spéciaux sont nécessaires.Par exemple, début 1960 des caractères sont spécifiés pour le langage FORTAN⁹. Par exemple un - en début de ligne indiquera que le papier doit être déroulé de 3 lignes avant de commencer l’impression¹⁰.

Ces charactères seront ensuite standardisé par l’ASA (American Standards Association)¹¹ dans un document nommé “ANSI X3.78-1981”¹². Ils seront donc connus sous le nom de “ASA carriage control characters”.

Sous Unix une commande nommé asa fera son introduction

(quand ?)

pour convertir les fameux charactère trouvés au début de chaque ligne en quoi que ce soit de nécessaire pour que l’imprimante utilisée derrière fasse ce qu’elle doit faire. asa est donc généralement utilisé en amont d’une commande lançant l’impression, typiquement lp. La spécification POSIX mentionne par exemple que certaines implémentations remplacent le + par le caractère ASCII de retour chariot

(pourquoi ne pas insérer directement le caractère, qu’est-ce qui vient avant l’autre ?)

.

Je me suis demandé pourquoi est-ce que les caractères ASCII n’étaient pas directement utilisés (CR LF LF LF plutôt que -). Je pense que l’explication vient du fait que l’ASCII a été publié en 1963¹³ et que le premier téléscripteur le supportant, le Teletype Model 33, a été commercialisé la même année. Les codes ASA et leurs usages pour FORTRAN prédateraient donc de quelques années l’ASCII.

at

Permet de programmer des commandes dans le futur un peu comme un crontab interactif non régulier. N’est pas vraiment obscure mais je ne la connaissais pas.

$ echo "seq 10" | at now +2 minutes

lancera seq 10 dans deux minutes. Permet de créer des queues de commandes qui s’exécuteront les une derrière les autres. Pour une personne comme moi qui se retrouve rarement dans d’autres situations que :

• lancer des commandes en direct hop hop hop
• programmer des commandes à intervalles réguliers dans un crontab.

l’utilité de at n’est pas évidente. On verra ça dans la commande batch. En arrière plan at utilise cron¹⁴.

batch

Fortement corrélée à at, batch permet de lancer une suite de programmes les un derrière les autres dans une queue. C’est un alias pour la commande at avec les options de queues.

Avant les systèmes d’exploitation tel qu’on les connaît aujourd’hui il existait des programmes ayant pour objectif de lancer des commandes les une derrière les autres. Les commandes étaient regroupées dans des lots (ou batch en anglais roll credits). A l’époque ces lots étaient physiques, un tas cohérent de carte perforées. Les ordinateurs de l’époque étant généralement monotâche, lents et toujours multi-utilisateurs¹⁵, la concurrence pour les ressources était rude. Les systèmes de traitement par lots on gagné en intelligence pour prioriser le lancement des commandes et des lots en fonction de la charge de l’ordinateur et des périodes d’activité[^15]. Au delà du simple fait de programmer le lancement d’un autre programme, c’est cette logique qu’assurent les commandes batch, at et nice. Cette idée de lancer, dans un certain ordre, plusieurs tâches à l’avenir sans qu’une personne ne l’ait demandé sur le moment, était novatrice à l’époque. Dans le bouquin “Unix Power Tools” il est rapporté que Jeff Summler appelait ça des “software robots”¹⁶.

Aujourd’hui si l’usage littéral de batch n’est plus très fréquent le concept perdure :

• dans les scripts des langages haut niveau. Un script shell est une suite d’instruction et de programmes à lancer les un derrière les autres.
• dans les environnements multi-utilisateurs¹⁷ contraints en ressource, typiquement les centres de calcul où l’on retrouve des systèmes de batch très sophistiqués tels que slurm
• dans le langage courant où un batch est entendu comme toute opération programmatique répétée sur ensemble de donnée. Par exemple générer toutes les pages HTML d’un site catium

cflow

Fait parti des nombreuses commandes que je ne connaissais pas parce que lié au développement. cflow parcours un fichier source et affiche dans la sortie standard un graph sous la forme d’un arbre. Par exemple :

$ cflow src/fzy.c src/options.c
main() <int main (int argc, char *argv[]) at src/fzy.c:17>:
    options_parse() <void options_parse (options_t *options, int argc, char *argv[]) at src/options.c:96>:
        options_init() <void options_init (options_t *options) at src/options.c:69>:
        [...]
        sscanf()
        usage() <void usage (const char *argv0) at src/options.c:37>:
            fprintf()
        atoi()
        strcmp()
        fprintf()
    choices_init()
    fprintf()
    [...]
    tty_interface_run()
    choices_destroy()

L’outil permet donc d’étudier et d’analyser le flot d’exécution d’un programme en parcourant l’arbre sans avoir à le compiler et l’exécuter. Il ne me semble pas (plus) beaucoup utilisé à en croire le peu de résultats d’une recherche sur le web.

La seule implémentation facilement accessible est celle de GNU¹⁸, débutée en 2005¹⁹ depuis une version datant au plus tard de 1997²⁰. Sur wikipedia il est inscrit que cflow apparaît pour la première fois dans System V²¹ sans aucune référence pour le prouver. Cela placerait sa publication au plus tôt en 1983²² soit trois ans avant GDB.

(Peut-être que ça l’a rendu obsolète ?) mille fois plus rapide mais maintenant fait plus trop de diff

les backends de compilateur ?

cksum

cksum calcul et vérifie la somme de contrôle d’un fichier donnée. Pour calculer le hach cksum utilise un algorithme de contrôle de redondance cyclique utilisé par Ethernet et donc extrêmement répandu²³. Cette fonction de hachage n’est pas considérée comme cryptographiquement sécurisée²⁴. Elle est maintenue pour des raisons de portabilité mais n’est réservée que pour les cas où l’on veut, au mieux, vérifier si le transfert d’un fichier s’est passé sans erreur accidentelle²⁵. Tout modèle de menace plus sérieux requiert l’utilisation de fonction de hachage cryptographique telle que SHA-2.

La version GNU de cksum inclue la possibilité d’utiliser d’autres algorithmes qui sont par ailleurs accessibles autrement. Les deux commandes suivantes calculent le même hash :

cksum -a sha256 fichier
sha256sum fichier

comm

Une commande sur laquelle il n’y a pas grand chose à dire en terme d’historique mais que j’ai trouvé particulièrement utile une fois pour ma gestion de playlist. Je ne l’avais jamais envisagé comme cela mais l’article wikipedia le compare à diff. Il est vrai que pour les usages courants de diff comm peut paraître obsolète. Pour un usage plus programmatique, dans des scripts et lorsque la sortie en TSV convient, comm peut être l’outil qu’il vous faut.

ed

ed est un éditeur de texte, le seul spécifié dans POSIX. De nombreux articles expliquent déjà l’histoire d’ed et ses liens avec des outils que nous connaissont aujourd’hui tels que vi et vim. Je recommande fortement cet article de Gustavo Pezzi. En plus du plaisir d’en apprendre plus sur des outils que l’on utilise, l’article rappelle habilement que, comme tout objet technique, la forme et les fonctionnalités des éditeurs de textes ont autant été informés par les conditions matérielles de leurs créations que par les idées des personnes les codant. Ainsi dans vi on se déplace avec hjkl entre autre parce que le clavier du développeur n’avait pas de flèches sur son clavier et vi est, encore jusqu’à aujourd’hui, plus “sobre” qu’Emacs parce que son développeur avait un modem extrêment lent.

Je ne résiste pas à l’idée à vous partager cette fameuse blague de Patrick J. LoPresti, écrite à une époque où l’usage d’ed se faisait déjà rare en comparaison avec vi et emacs : https://www.gnu.org/fun/jokes/ed-msg.txt

La blague du premier paragraphe, c’est à dire le fait de justifier l’usage d’ed par son adéquation avec un téléscripteurs déjà considéré obsolète pour l’époque, résonne en moi. Avec les copaines de Katzele nous utilisons parfois cet argument au premier degré pour justifier certains de nos usages ou suggérer des modifications : “Le site est cool mais je ne peux pas le consulter dans lynx sur mon raspberry 1 !”.

Cette blague a été postée sur le newsgroup alt.religion.emacs (ce qui est déjà drôle en soit) et on peut y trouver des réponses dans cette archive tenue par Google (désolé). On y voit en particulier que la blague éternelle de ne pas savoir quitter vim était, en 1991, faite à propos d’ed :

James D. Oliver III :
So how do you get out of ed? The only thing I could manage was to Ctrl-Z and then kill the job.

On peut voir dans cette vidéo de la BBC un présentateur utiliser un programme du style d’ed pour faire une modification à l’aide d’une commande qui ressemblerait beaucoup à s/Fred/Mary/g dans ed²⁶.

Bien que, au delà de la blague, ed soit réellement l’éditeur de texte le plus standard dans le monde d’Unix, il n’est pas disponible par défaut sur de nombreuses distributions Linux y compris Debian²⁷. Il y a eu une tentative de l’ajouter à nouveau mais sans succès²⁸, je vous laisse lire les arguments pour et contre. Cette absence ne concerne pas que ed. Beaucoup de commandes dans POSIX ne sont plus essentielles pour le bon fonctionnement des Unix modernes et puisque presque aucun ne cherche activement à obtenir la certification mais seulement en être proche²⁹, ces commandes passent à la trappe. L’un des arguments en faveur du l’absence du paquet ed dans l’installation par défaut est la faible utilisation du paquet. A ce sujet un utilisateur pointe vers les statisques maintenues par debian. Ooooooh le beau graph généré avec gnuplot ! On reconnait là le style w lp et la belle couleur violette par défaut. Les tics de l’axe des abscisses pourrait être amélioré avec un petit set xtics rotate by -45 offset 5,0.

ctags

ctags parcourt du code C et créer un fichier indexant les fonctions, les structures etc.