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.
free
total used free shared buffers cached
Mem: 32634444 27410980 5223464 376440 93224 18234220
-/+ buffers/cache: 9083536 23550908
Swap: 0 0 0
free -h
total used free shared buffers cached
Mem: 31G 26G 5.0G 370M 91M 17G
-/+ buffers/cache: 8.7G 22G
Swap: 0B 0B 0B
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.
df /dev/nvme0n1p1 /dev/sdb Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur /dev/nvme0n1p1 239314556 50879376 176208928 23% / /dev/sdb 1921803544 620797656 1203313776 35% /media/cascador/Data df -h /dev/nvme0n1p1 /dev/sdb Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/nvme0n1p1 229G 49G 169G 23% / /dev/sdb 1,8T 593G 1,2T 35% /media/cascador/Data
É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
Les commentaires sont fermés.
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)…
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.
Je vais faire une réponse collective ^^
Je valide complètement l’argument de la compatibilité. Pour autant je prends comme exemple Debian Buster, il y a des liens symboliques de /bin et /sbin vers /usr/bin et /usr/sbin, à terme /bin et /sbin disparaîtront. Preuve qu’on peut modifier des choses (en laissant le temps) et qu’il est évidemment nécessaire de le faire.
je n’ai pas le même avis que toi sur le fait que df, free seraient appelés plus de fois par des scripts que le nombre de fois où un **sysadmin** va utiliser ces commandes. Il faut remplacer **sysadmin** par **utilisateur**, un mec sur son pc à la maison n’est pas sysadmin.
Tcho !
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.
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.
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.
Tcho !
Et je rejoint l’avis de , ces commandes sont largement plus utilisée par d’autres programmes que directement par un utilisateur.
Professionnellement je suis sysadmin, power-user dans ma vie privée. Cependant je mets de côté tout ça pour parler en tant qu’utilisateur et des utilisateurs (simples utilisateurs, développeurs, sysadmin, jeunes, vieux…).
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.
Ma conclusion est justement de souligner que ces outils ne sont pas tournés vers l’utilisateur, les arguments vus ici (compatibilité, utilisation d’un alias) sont surtout valables pour le monde professionnel.
Tcho !
Je ne sais pas comment je dois prendre ton commentaire, quand je lis « Ces programmes ne sont pas fait pour donner un retour lisible par un être humain », je me dis en fait on fait des outils/programmes pas pour les utilisateurs ?
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 ?
Tcho !
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.
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.
Ha ha ha la réponse honteuse ^^ T’es un utilisateur lambda, tu utilises pas (du tout) la ligne de commande, « c’est pour les grands » ha ha.
Pour moi l’utilisateur lambda peut être amené à utiliser free, df, ln et la ligne de commande. Si la réponse est de dire que la ligne de commande est pas user-friendly de toute façon, il y a en effet plus de problème.
Tcho !
On part sur un sujet différent si le but est d’être débutant-friendly, déjà ce terme n’existe pas et je recommanderai comme toi uniquement des applications graphiques.
Je trouve cependant l’ensemble des commentaires très convaincus que l’utilisateur lambda n’utilise pas (du tout) la ligne de commande. Quand j’ai débuté sur GNU/Linux, je n’avais aucune connaissance, je faisais tout en ligne de commande : MAJ, lspci, sources.list, etc.
Tcho !
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.
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).
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".
Il ne faut pas être déçu de ma remarque, ce n’est que mon opinion ^^
Il est probable que je rebondisse sur cet article dans un « En retour : User-friendly, human-readable ».
Tcho !