Après, vu la taille de ce que je publie, j'écris tout dans un fichier texte avant de poster pour ne rien perdre au cas où il y ait un plantage ou que je doive attendre avant de poster (pour faire des corrections, par exemple). Ça me fait faire plein de copier-coller, c'est assez pénible, mais c'est indépendant de Markdown.
Pour en revenir au propos, il y a de tout et cette commande n'est pas POSIX... J'aurais du indiquer « 75/72/70 » au lieu de « 72 » ; ou alors « 75 » qui est la valeur des implémentations les plus couramment rencontrées ?
Je ne sais pas. En tout cas, à l'usage, je vois que fmt coupe à 72 et pas avant. Si j'ai une ligne de 80 caractères ou plus, c'est au caractère 72 qu'il coupe. Si le goal est de 65, il pourrait couper avant, je lui en laisse l'occasion.
Donc soit il y a un problème dans la page de manuel, soit je n'ai pas compris ce que sont le goal et le maximum.
Ce journal remet certaines commandes en contexte.
Ça fait du bien de savoir d'où viennent les commandes disponibles sur nos systèmes. Je ne connais que trop peu la très grande majorité des commandes qui me sont disponibles, et encore moins leur utilité initiale. Je compte 2724 programmes sur mon système, c'est colossal et je n'ai pas la moindre idée de ce à quoi servent peut-être la moitié d'entre eux.
Je suis d'accord avec l'article que tu as cité, ainsi qu'avec les articles que lui-même cite, Unix était très lié au langage lui-même. Nos systèmes actuels sont très fortement liés, encore aujourd'hui, au langage et c'est un élément un peu trop oublié de nos jours.
Je m'explique. Dans Unix et ses dérivés plus modernes, un paquet de commandes introduisent leur propre langage : dc, bc, sed, awk... la liste est longue. À chaque fois, c'est un nouveau langage qu'il faut apprendre, mais c'est également un langage adapté à ce qu'on cherche à faire, lié à un usage. Et ça, c'est magnifique. Pour moi c'est toute la beauté de l'approche Unix : une tâche = un outil, voire un langage. Ce n'est malheureusement pas assez exprimé de cette façon dans les explications sur Unix, pourtant cela fait sens.
Et quand on comprend ça, ça fait d'autant plus détester les outils modernes qui veulent tout réduire à quelques langages de programmation, là où la diversité des approches permettaient de ne manipuler que la complexité inhérente à la tâche à laquelle on s'attaquait. Autrement dit, pourquoi vouloir tout résoudre avec Javascript, Java ou Python, quand on a accès à des langages plus pertinents dans bien des cas ?
Et là, on pourrait parler de plein de dérives actuelles, la liste n'en est que trop longue. Le JavaScript dans le navigateur n'était pas suffisamment ridicule qu'on a voulu l'intégrer au système : pouf, node ! Python n'apporte strictement rien de neuf par rapport à Perl, mais allons-y pour le développer jusqu'à l'intégrer à plein d'outils systèmes pour avoir une forte dépendance à ce langage alors qu'il sert à rien. Deux langages qui ont une base de code de plus d'un million de lignes chacun, c'est parfaitement raisonnable...
Pendant ce temps-là, awk a été implémenté dans toybox en 2700 lignes.
Je pense sincèrement qu'on dérive. Nos usages sont de moins en moins raisonnables. Les langages créés pour l'occasion dans Unix servaient un usage, une fonction bien particulière. De nos jours, nous inventons des langages qui se veulent génériques, pour résoudre tout type de problème, et nous les intégrons à nos machines sans plus de considération. C'est une erreur que de rejeter la simplicité en faveur de l'unicité des langages. Je préfère connaître 3 langages simples appris en 1h chacun, qu'un langage qui évolue jusqu'à nécessiter des compilateurs (ou interpréteurs) de plusieurs centaines de milliers de lignes de code.
[^] # Re: Super journal... que je lirai plus tard
Posté par karchnu (site web personnel) . En réponse au journal rétrospective sur la mise en page en console. Évalué à 3. Dernière modification le 10 février 2022 à 03:26.
Je suis bien d'accord !
Après, vu la taille de ce que je publie, j'écris tout dans un fichier texte avant de poster pour ne rien perdre au cas où il y ait un plantage ou que je doive attendre avant de poster (pour faire des corrections, par exemple). Ça me fait faire plein de copier-coller, c'est assez pénible, mais c'est indépendant de Markdown.
Je ne sais pas. En tout cas, à l'usage, je vois que
fmtcoupe à 72 et pas avant. Si j'ai une ligne de 80 caractères ou plus, c'est au caractère 72 qu'il coupe. Si legoalest de 65, il pourrait couper avant, je lui en laisse l'occasion.Donc soit il y a un problème dans la page de manuel, soit je n'ai pas compris ce que sont le
goalet lemaximum.Ça fait du bien de savoir d'où viennent les commandes disponibles sur nos systèmes. Je ne connais que trop peu la très grande majorité des commandes qui me sont disponibles, et encore moins leur utilité initiale. Je compte 2724 programmes sur mon système, c'est colossal et je n'ai pas la moindre idée de ce à quoi servent peut-être la moitié d'entre eux.
Je suis d'accord avec l'article que tu as cité, ainsi qu'avec les articles que lui-même cite, Unix était très lié au langage lui-même. Nos systèmes actuels sont très fortement liés, encore aujourd'hui, au langage et c'est un élément un peu trop oublié de nos jours.
Je m'explique. Dans Unix et ses dérivés plus modernes, un paquet de commandes introduisent leur propre langage :
dc,bc,sed,awk... la liste est longue. À chaque fois, c'est un nouveau langage qu'il faut apprendre, mais c'est également un langage adapté à ce qu'on cherche à faire, lié à un usage. Et ça, c'est magnifique. Pour moi c'est toute la beauté de l'approche Unix :une tâche = un outil, voire un langage. Ce n'est malheureusement pas assez exprimé de cette façon dans les explications sur Unix, pourtant cela fait sens.Et quand on comprend ça, ça fait d'autant plus détester les outils modernes qui veulent tout réduire à quelques langages de programmation, là où la diversité des approches permettaient de ne manipuler que la complexité inhérente à la tâche à laquelle on s'attaquait. Autrement dit, pourquoi vouloir tout résoudre avec Javascript, Java ou Python, quand on a accès à des langages plus pertinents dans bien des cas ?
Et là, on pourrait parler de plein de dérives actuelles, la liste n'en est que trop longue. Le JavaScript dans le navigateur n'était pas suffisamment ridicule qu'on a voulu l'intégrer au système : pouf,
node! Python n'apporte strictement rien de neuf par rapport à Perl, mais allons-y pour le développer jusqu'à l'intégrer à plein d'outils systèmes pour avoir une forte dépendance à ce langage alors qu'il sert à rien. Deux langages qui ont une base de code de plus d'un million de lignes chacun, c'est parfaitement raisonnable...Pendant ce temps-là,
awka été implémenté danstoyboxen 2700 lignes.Je pense sincèrement qu'on dérive. Nos usages sont de moins en moins raisonnables. Les langages créés pour l'occasion dans Unix servaient un usage, une fonction bien particulière. De nos jours, nous inventons des langages qui se veulent génériques, pour résoudre tout type de problème, et nous les intégrons à nos machines sans plus de considération. C'est une erreur que de rejeter la simplicité en faveur de l'unicité des langages. Je préfère connaître 3 langages simples appris en 1h chacun, qu'un langage qui évolue jusqu'à nécessiter des compilateurs (ou interpréteurs) de plusieurs centaines de milliers de lignes de code.
Bref, fin de la digression.