Adoption des sinogrammes pour les options courtes des programmes GNU

Posté par (page perso) . Édité par Davy Defaud, ZeroHeure et Yvan Munoz. Modéré par ZeroHeure. Licence CC by-sa
29
1
avr.
2018
Humour

C’est une petite révolution du côté des coreutils, des built‐ins Bash et de tous ces petits programmes du projet GNU qu’on utilise sans même y penser : ceux‐ci voient arriver un changement majeur à leur syntaxe, qui va consister à utiliser des sinogrammes (caractères chinois) pour remplacer les options courtes, c’est‐à‐dire les options qui étaient jusqu’à aujourd’hui composées d’un tiret et d’une seule lettre de l’alphabet latin. Cette évolution est motivée par la pénurie de plus en plus pressante de lettres pour les options de certaines commandes, au développement desquelles elle devrait donner un nouveau souffle.

Interrogé lors d’une récente conférence à Paris, Richard Stallman lui‐même a déclaré : « J’approuve ce changement car ces programmes seront toujours distribués sous la licence publique générale GNU, version 3 ».

Tous les détails dans la suite de la dépêche.

Le monde change mais les commandes Shell restent les mêmes. C’est à la prestigieuse conférence pluridisciplinaire BAHFest London qu’a été dressé ce constat pour le moins amer. Et de pointer du doigt un coupable inattendu : l’alphabet.

La communauté du Libre ne manque pas de créativité, y compris dans le domaine des programmes en ligne de commande ; en témoigne l’existence d’alternatives modernes à de nombreuses commandes historiques, comme celles mentionnées dans une dépêche récente. Mais celles‐ci peinent à trouver leur place, en raison, bien sûr, de leur nom différent. C’est donc aux programmes existants d’évoluer, autrement dit aux projets GNU eux‐mêmes. Mais à quoi bon l’ajout de nouvelles fonctionnalités si l’on ne peut y accéder ? De nouvelles fonctionnalités demandent de nouvelles options ; et des options courtes, bien sûr, pour les développeurs pressés que nous sommes. C’est là que le bât blesse : les commandes sont à court d’options courtes.

Voici l’utilisation des lettres de l’alphabet dans les options courtes de quelques commandes courantes (l’utilisation plus rare des chiffres est donnée à titre indicatif). On voit que plusieurs commandes utilisent presque toutes les lettres minuscules disponibles et une bonne partie des lettres majuscules.
Options courtes utilisées par plusieurs commandes courantes

De plus, comme pour les adresses IPv4, la pénurie des options courtes pour une commande se fait sentir bien avant l’épuisement total de l’alphabet. Le besoin de signification intuitive empêchant a priori d’utiliser n’importe quelle lettre pour n’importe quelle fonction. À l’instar du protocole Internet, la solution au problème des options courtes est donc claire : augmenter drastiquement le nombre de valeurs possibles, tout en restreignant ces valeurs aux caractères uniques. Les sinogrammes répondent parfaitement à ce cahier des charges et sont, comme nous allons le voir, tout à fait pertinents pour répondre au besoin de signification intuitive des options.

Les plus perspicaces feront remarquer que les commandes Shell impliquent généralement des notions techniques qui n’ont pas de sinogrammes dédiés mais se traduisent en mandarin par des mots de plusieurs sinogrammes, en contradiction avec la notion d’option courte. Pour cette raison, utiliser les sinogrammes dans leur sens littéral n’est pas une solution acceptable. Au lieu de cela, la signification des sinogrammes utilisés sera réinventée à partir de leurs éléments de base dans le contexte du Shell.

Voici par exemple trois sinogrammes qui apparaissent comme composants dans de nombreux autres et l’interprétation qui en sera faite dans le Shell :

Caractère Signification en chinois Signification dans le Shell
人 (rén) Personne, être humain Utilisateur, humain
口 (kǒu) Bouche, ouverture Sortie d’un programme
木 (mù) Arbre Arborescence, données structurées

Ces éléments de base seront ensuite composés pour définir des options telles que :

Option En chinois Effet de l’option
-㕥 (shēn ou yǐ) (bouche + personne) Gémir ou Pour, ainsi Sortie plus lisible pour un humain (comme -h pour certaines commandes)
-呆 (dāi) (bouche + arbre) Stupide Sortie JSON ou XML (selon une variable d’environnement par exemple)
-保 (bǎo) (personne + bouche + arbre) Protéger Sortie HTML

Ce changement concernera au début les coreutils et les commandes intégrées à Bash, puis sera étendu à tous les projets GNU. Et l’on peut espérer que d’autres projets tels que zsh se mettront rapidement à la page (un greffon oh-my-zsh est d’ores et déjà disponible en préversion).

Les règles qui permettront de définir des options courtes intuitives restent bien sûr à préciser. Plusieurs contributeurs historiques du projet Emacs se sont attelés à la tâche, ayant déclaré qu’ils « ne pouvaient rester à l’écart d’un tel défi ».

En parallèle de cet effort, des développeurs de plusieurs distributions réfléchissent à standardiser un mécanisme de modification du PATH pour le Shell semblable à l’importation de modules dans les langages de programmation généralistes. Ceci, vous l’aurez deviné, est motivé par un mouvement d’utilisateurs qui protestent contre l’adoption des caractères chinois et plaident pour que les katakanas japonais soient utilisés à leur place. Selon leurs défenseurs (dans un débat sur la liste kana-opts@vim.org), les katakanas, bien que peu nombreux comparés aux sinogrammes, auraient pour avantages leur notoriété préexistante dans la culture geek et informatique mondiale, ainsi qu’une meilleure lisibilité avec les polices à chasse fixe des terminaux. Le principal intérêt de la généralisation de la notion de module Shell sera, on l’espère, de trancher ce débat et tant d’autres par un ou plusieurs forks amicaux des programmes concernés.

Red Hat, pour sa part, a révélé travailler sur un projet logiciel unique fusionnant les notions de terminal, de Shell, de multiplexeur et Shell distant pour s’affranchir de contraintes d’architecture qui remontent à l’époque des terminaux physiques. On ignore encore si ce projet, qui s’ouvrira bientôt aux contributions de la communauté, pourrait rendre obsolètes les coreutils GNU.

Enfin, du côté des systèmes d’exploitation libres non basés sur Linux, on peut noter la réaction positive de Theo de Raadt sur misc@openbsd.org : celui‐ci a annoncé, dans le souci constant de l’interopérabilité d’OpenBSD avec les outils GNU, l’adoption prochaine d'UCS-2 comme codage de caractères par défaut du système.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.