User-friendly, human-readable

Pourquoi faut-il taper l’option -h des commandes df et free ? Les développeurs de ces outils pensent que cette option est superflue ?

Personnellement une option nommée --human-readable (-h), je pense qu’il serait utile, opportun et judicieux de l’intégrer par défaut.

Je n’ai pas assez de barbe pour apprécier la notation « moins human-readable » (sans -h). On passe à un niveau supérieur avec la commande df.

Évidemment la notation « moins human-readable » a des qualités : Plus précise, utile dans des scripts. Cependant à l’heure de l’utilisation de disques en To, il faudrait peut-être s’éloigner d’une notation précise pour se rapprocher d’une notation plus lisible, compréhensible et simple pour l’utilisateur (user-friendly).

Norme et exception (usage par défaut et option)

Cette question rejoint une interrogation plus large chez moi, quand doit-on opérer une bascule entre norme et exception ?

Si 9 fois sur 10 la majorité des utilisateurs font df -h ne faut-il pas considérer -h comme une norme de facto et plus une option ? Et alors modifier le code de df pour que de base sans devoir préciser -h df renvoie les infos en human-readable. Bien entendu une nouvelle option serait ajoutée afin de conserver la notation « moins human-readable » qui reste nécessaire. df en human-readable deviendrait la norme, la notation « moins human-readable » l’exception.

Au doigt mouillé 98% des personnes utilisent la commande ln pour créer un lien symbolique (symbolic link) ln -s, pourquoi ln crée un hard link par défaut ? Le hard link est l’exception dont on se sert 2 fois de l’an et le lien symbolique la norme, quand les développeurs de la commande ln vont la modifier pour qu’elle crée un lien symbolique par défaut ?

La façon dont l’outil est conçu et codé rentre en compte, je ne me suis pas penché sur le code de ln mais je suppose qu’il y a de bonnes raisons à ce que la création d’un hard link soit le choix par défaut. Enfin j’espère.

Remettre l’utilisateur au centre

Cela ne change en rien ma réflexion, en 2020 tout outil devrait être tourné vers l’utilisateur, être user-friendly et human-readable par défaut. Devoir utiliser free -h, df -h, ln -s revient à devoir préciser qu’on est humain et l’utilisation naturelle et simple qu’on veut de l’outil.

Déjà 21 avis pertinents dans User-friendly, human-readable

  • Rémi
    Je suis d’accord sur le principe avec toi, le (très) gros problème c’est la régression que cela engendrerait : tous les scripts / programmes qui utilisent ces commandes, notamment les 2 premières sans le -h devraient être mis à jour !
    Je n’ose même pas imaginer l’impact que cela pourrait avoir de modifier le comportement par défaut de ces fonctions élémentaires (au sens de fonctions de base sur lesquelles se basent de nombreuses autres)…
  • alf
    La raison pour laquelle cela ne changera pas est simple: compatibilité avec les anciens scripts. Ces outils étant très utilisés, et depuis longtemps, modifier un comportement risque de casser pas mal de choses en amont; une modification demanderait de s’assurer qu’elle ne fasse pas de dommages collatéraux par ailleurs. Certes, ces problèmes sont issus d’un mauvais choix de départ des options par défaut, mais corriger ce problème risque d’en créer d’autres plus important.
  • Dom
    Il suffit de créer un alias dans le .bashrc (si on utilise bash) : alias df=’df -h’. On revient dans le mode standard avec le backslash devant : \df. Changer le mode par défaut planterait tous les scripts qui existent déjà, donc il ne sera pas possible de réaliser ce qui est demandé.
  • Changer le comportement par défaut casserait les myriades de scripts et applications qui reposent sur ces outils, rien que ça c’est probablement une raison suffisante pour ne jamais y toucher.

    Mais ensuite je pense que c’est aussi parce qu’ils ont été pensé principalement pour ce genre d’utilisation (philosophie UNIX « piper » les programmes entre eux, tout ça…), et je pense aussi que le nombre de fois où ces programmes sont appelés par des scripts (en arrière plan, cron ,etc.) dépasse largement le nombre de fois où un sysadmin va utiliser ces commandes.

  • Daiko
    Pour moi c’est pour ne pas perdre d’information. Convertir un temps des secondes vers les minutes ou les heures perd de l’information et ne permet pas de revenir en arrière (Si l’on conserve des entiers). Et c’est valable pour toute les informations de mesure.

    J’y vois aussi l’éternel débat entre simple et facile. Afficher des octets est simple et précis (plus petite unité). Si il faut en plus afficher une unité (K, M) cela devient complexe a gérer, par contre c’est plus facile a lire (même si le processus derrière est complexe même pour une utilisateur lambda, mais nous n’en avons pas conscience). Je pense que la technologie doit rester simple, il est toujours possible d’ajouter une couche pour l’ergonomie.

  • L’inverse est vrai également. Malgré tout le respect que j’ai pour ces commandes, je trouve un peu hasardeux de prendre la sortie et de la tronçonner/parser à coups de awk/sed/perl pour obtenir des valeurs à la base desquelles calculer.
    On voit fleurir ça et là des –json et allié avec jq c’est sympa. Je ne sais pas quel est le format idéal à privilégier pour les sorties (json offre un bon compromis je trouve) mais je pense que le tsv n’est pas le plus adapté pour les scripts.
  • gilcot
    Le doigt mouillé ne remplacera jamais la multitude de besoins pour laquelle il existe déjà une solution : les alias ! Tu fais systématiquement du « df -h » alors tu peux rajouter dans ton fichier d’initialisation quelque chose comme « alias df=’df -h’ » et basta. Moi j’utilise plus souvent d’autres options, comme « df -i » d’une part, et si ta proposition avait été il aurait fallu inventer une autre option (inhuman-readable ?!?) pour que je puisse utiliser la commande dans les scripts (c’est quand même plus simple de comparer une seule unité de base que de devoir se battre avec les suffixes…)

    Et sinon, pour répondre à la question du besoin d’origine, beaucoup de commandes ne sont pas nées avec l’option « -h » car UNIX est né à une époque où on n’avait pas à gérer des gibi et des tibi de données. Une fois sorti du Bell Labs, les options ajoutées et qui correspondaient aux besoins de l’époque permettaient de de ne pas afficher le nombre de blocs mais convertis en kibi, et ça ne pouvait (et ne peut toujours pas) être par défaut car ne correspondant pas à la réalité de tous les matériels supportés.

    Mes deux sous.

  • Bruno
    Ces programmes ne sont pas fait pour donner un retour lisible par un être humain, d’où l’option –human-rdeable, mais pour donner des valeurs *exactes* utilisables pour des scripts, outils de surveillance ou de métrique. Les valeurs de type 31G ne sont pas exactes et pas utilisables pour faire des calculs subséquents. D’ailleurs quand a-ton un retour en M en G ou en T ? En Gio ou en Go ?
    Et je rejoint l’avis de , ces commandes sont largement plus utilisée par d’autres programmes que directement par un utilisateur.
  • Personnellement, j’estime que l’utilisateur lambda n’utilisera pas la ligne de commande pour ça. Du coup c’est pas un problème. Si le but est d’être débutant-friendly, alors déjà les commandes sont pas adaptées quelque soit les options : elles ne sont pas toutes évidentes et demandent un apprentissage. Une GUI sera plus adaptée.

    Je vois pas l’intérêt d’adapter les commandes à des utilisateurs qui ne s’en serviront jamais, surtout vu les dégâts que ça causerait ? Le ratio gain/perte ne vaut pas le coup.

    Ou alors, faire un nouvel outil sous un autre nom. LVM par exemple a des commandes dédiées aux utilisateurs et d’autres aux machines. SystemD aussi (status pour l’humain, show pour la machine). Y’a plein de noms dispos, et potentiellement plus clairs que les originaux. Et à terme ils pourraient remplacer les originaux si vraiment le besoin en est. Voire même en drop-in (comme bash qui fourni sh et se comporte différemment selon ce qui a été appelé. Ou vim qui peut remplacer vi/view en se comportant différemment si appelé via ces commandes). Mais à mon avis ce n’est pas nécessaire. Il est fort probable que le simple utilisateur qui fait un df l’aura copié/collé et peut donc copier le -h en plus sans souci.

  • > Disons que je valide ton hypothèse, en tant qu’utilisateur si je veux connaître l’espace occupé sur mes systèmes de fichiers, j’utilise quel outil ou je fais quoi du coup ?

    Comme les « vrais » utilisateurs (et pas les sysadmin et powerusers), tu utilises gnome-disk-utility (ou équivalent) ;-P Un utilisateur lambda ne devrait pas à avoir à ouvrir un terminal.

  • J’ai inventé le terme parce que user-friendly n’a pour moi aucun sens. Pourquoi ne serait-je pas un utilisateur ? Et l’utilisateur lambda qui fait tout en CLI n’en est déjà plus un. J’en ai fait partie. Je suis devenu adminsys depuis. Soyons honnêtes. Quand on débute on utilise la CLI pour deux raisons : soit en comprenant que dalle parce qu’on nous a dit de faire comme ça (débug, etc), soit par curiosité. Dans ce second cas on fait un effort d’apprentissage, et c’est pas un petit -h qui va poser problème, et les alias arriveront rapidement dans la foulée.

    Au final mon point ne change pas : la quantité de choses qui casseraient face au gain que ça apporterais pour les rares utilisateurs non-initiés qui n’utilisent que peu la CLI est pas intéressant. La CLI est pas faite pour être intuitive ou facile pour tout un chacun, mais pour ceux qui vont s’en servir quotidiennement et probablement de façon avancée.

    Le principal soucis c’est que beaucoup d’outils sont conçus pour être utilisés en script avant tout. Et c’est normal en soit, la puissance du shell étant de pouvoir tout lier simplement (vive les oneliners lol). Certains outils sont également utiles interactivement, du coup au lieu de dupliquer on a juste ajouté une option. Qui n’a jamais utilisé cat pour afficher un fichier après tout ? C’est pas du tout le but de cat à la base.

    Si on veut se tourner vers l’utilisateur, on fait des wrappers, des alias, des interfaces (TUI/GUI) mais la CLI pour moi sera toujours un outil d’automatisation avant tout. Je suis pas spécialement contre faire des outils pour les humains en CLI, ceci dit (et il y en a, comme ncdu pour du, ou bat pour cat, et j’en passe), mais contre changer le comportement des outils de base, si.

  • Yoko
    Salut

    Tout simplement parce que ça flingue la Single UNIX Specification. Oui l’implémentation GNU prend déjà certaines libertés, mais la plupart du temps c’est compatible avec le standard.

    Si tu ne veux pas créer un alias, utilise l’une des nombreuses alternatives. Si tu ne veux pas avoir à l’installer, choisi une distribution qui les installe par défaut. Ces commandes sont faites pour un standard minimum que tu trouve sur l’ensemble des unix, gnu n’est pas la seule implémentation et tu peux retrouver cette commande sur les BSD et dans des unix propriétaires. C’est un peu le principe en fait, comme le fait de ne pas présenter de couleur par défaut dans ls par exemple. make, ls, du, vi,… ne sont pas à la pointe des besoins utilisateurs car leur job c’est d’être des implémentations valides de standard.

    C’est comme utiliser htop à la place de top, utiliser ripgrep à la place de grep,… à partir du moment où le binaire ne répond pas à un nom qui fait parti du standard il fait bien ce qu’il veut (et certains se comportement différemment selon comment on les appels bash devient plus compatible s’il est appelé sh par exemple, pareil avec vim si on l’appel vi voir ex).

  • oui j’ai hésité à la faire cette réponse j’avoue… (^_^’) dans mon monde idéal à moi tout le monde devrait avoir un minimum de savoir faire sur ce avec quoi il interagit. Je devrais être capable de diagnostiquer ma moto ou mon micro-ondes en panne, etc. Mais malheureusement (?) on est pas dans mon monde idéal, on est dans un monde où la division du travail est poussée à l’extrême.
  • Erwann
    > Perso en tant qu’utilisateur j’en ai rien à foutre que la sortie de df arrange sysadmins/dev/pros, casse la compatibilité, pose problème dans les scripts. En tant qu’utilisateur je lance un outil, j’attends qu’il soit bien pensé. La sortie actuelle d’un df est en effet pertinente pour les pros si on s’en sert pour des scripts/outils, pour un utilisateur lambda je pense qu’elle devrait être en human-readable. <

    Salut Cascador,
    ta remarque m'étonne et me déçoit.
    Toutes les remarques précédentes vont dans le même sens : compatibilité avec les scripts existant ; on parle quand même de plus de 40 années (en fait 50) d'administration système Unix.
    Je suis automaticien. En ce qui concerne les activités d'ingénierie / configuration / développement applicatif, le premier système de contrôle-commande que j'ai utilisé permettait de TOUT faire en ligne de commande (années 1980). Avec les collègues, nous avions une foultitude de scripts – très souvent des scripts qui généraient d'autres scripts – pour réaliser toutes les activités de configuration, de vérification, d'administration système.
    D'autres groupes travaillaient seulement en mode "interactif". Nous faisions à 5 ingénieurs le travail de 12 à 15 personnes. Cerise sur le gâteau, nous n'avions que très peu d'erreur, car il est beaucoup plus simple et fiable de revoir les paramètres d'entrée d'un script que de vérifier des saisies de manière interactive a posteriori.

    La force des systèmes de type Unix est le capacité à scripter simplement. Effectivement, en CLI, l'utilisateur de base passe au second plan. Ce n'est pas grave, car de nombreux utilitaires "graphiques" sont disponibles pour être "user friendly" / "human readable".

    Pour info, je suis fatigué des questions relatives à l'horodatage dans les applicatifs.
    Chacun y va de son propre format (chaîne de caractère), trop souvent en ne suivant même pas la norme (ISO 8601) et posant des montagnes de problèmes lorsque l'application est utilisée sur plusieurs fuseaux horaires (sans compter le passage à l'heure d'hiver).
    Il serait tellement fonctionnellement plus simple et plus économique en place, de simplement stocker la valeur 32 / 64 bit retournée par getsystemtime() et de ne procéder à une visualisation "human readable" que lors de l'affichage de la valeur (à l'écran ou dans les rapports générés).

    En ligne de commande, la sortie par défaut devrait toujours être dans un format simplement scriptable et "pipable".

Laisser un commentaire

indique des champs obligatoire.