Gil Cot ✔ a écrit 6272 commentaires

Attention que YAML a beaucoup beaucoup de cas spéciaux… https://yaml.org/spec/ (ce qui rend l'utilisation de bash pas du tout trivial …à supposer qu'on y arrive.)
Il faut peut-être se caler sur StrictYAML ? https://github.com/crdoconnor/strictyaml#design-justifications

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Ah mais j’en fais et j’aime beaucoup ce langage :D Justement, j’évite les trucs implicites (et du coup je ne comprends pas quand les gens balancent sur Internet que Perl = automatiquement illisible etc.)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Je présume que tu utilise l’implémentation GNU sed car il me semble (mais faut que je vérifie) que \s n’est pas standard…

Pour la performance, ce n’est pas lié qu’à la taille (qui reste un atout important au niveau du chargement et de l’exécution quand il y a de la charge) mais plus aux actions effectuées (et avec quels algorithmes.)
TR va parcourir le flot et faire des remplacements à la volée (du moins c’était aussi trivial avant de devoir prendre en compte les encodages multiple octets.)
SED doit séquentiellement parcourir les lignes du fichier en retenir celles qui correspondent puis appliquer le traitement demandé à la ligne. Cette approche est par nature forcément plus lente.
Il y a typiquement des choses que les petits utilitaires ne savent pas faire (par exemple substituer un caractère par un autre c’est bon, mais remplacer un mot par un autre non), et en général (presque tout) ce que tu ferais manuellement dans un éditeur de texte sied à Sed …qui a été pensé comme pendant de scriptage de Ed/Ex. D’un autre côté, les enchaînements de pipe ne sont plus performants quand il y en a trop (j’ai compté une dégradation à partir de cinq sur une vieille bécane il y a longtemps, et puis de toute façon pour la gestion des erreurs on repassera) et surtout sur de gros volumes. Là, pouvoir faire dans le même programme plutôt que plusieurs processus qui s’attendent est mieux.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

et cut, si on lui indique l’espace comme séparateur, considère alors qu’il s’agit de plusieurs champs vides. Comportement qui a sûrement une bonne raison d’être, mais que je ne saisi pas.

C’est que la plupart de ces outils viennent d’une époque où les choses devaient être KISS et là il s’agit de pouvoir manipuler des fichiers DSV tous bêtes (contrairement à cette immondice de CSV…) Un exemple connu de ce type est le fichier /etc/passwd (et aussi la variable PATH) avec -d ':'

jsmith:x:1001:1000:Joe Smith,Room 1007,(234)555-8910,(234)555-0044,email:/home/jsmith:/bin/sh

l’équivalent pour Markdown, sauce GFM et similaires, serait avec -d '|'

jsmith|x|1001|1000|Joe Smith,Room 1007,(234)555-8910,(234)555-0044,email|/home/jsmith|/bin/sh

et tu pourrais avoir une application qui utilise des espaces, soit -d ' '
(dans tous les cas, il faut éviter la collision de délimiteur —par exemple avec le blanc souligné ici mais ce pourrait être un autre espacement comme l’insécable)

jsmith x 1001 1000 Joe_Smith,Room_1007,(234)555-8910,(234)555-0044,email /home/jsmith /bin/sh

Avec ce type de format, DSV, la convention a toujours été que tous les champs soient présents, même vides. Dans ce cas, on a deux successions de délimiteur…

jsmith:x:1001:1000::/home/jsmith:/bin/sh

…règle qui ne change pas selon le délimiteur (on a dit kiss, pas avec des exceptions comme en français)

jsmith x 1001 1000  /home/jsmith /bin/sh

(dans cet exemple, en ayant changé le délimiteur, on ne casse pas notre cut -d ' ' -f 6 héhé)

Alors que awk considère les espaces multiples comme un seul séparateur.

C’est un poil plus subtil. Quand AWK ont mis au point l’outil, c’était pour traiter des fichiers avec une structuration un peu plus complexe et ils ont prévu de pouvoir pratiquement tout définir (comprendre décrire le format du fichier…) Du coup, au lieu de travailler ligne par ligne, leur programme gobe tout le fichier et se fait un tableau interne dont les lignes sont découpées au niveau de la valeur de RS (qui est le saut de ligne par défaut) et les colonnes/champs (cette fois-ci variables —i.e. contrairement à du DSV toutes les lignes ne sont pas obligées d’avoir le même nombre de champs) au niveau de FS (qui est toute succession de blancs par défauts, comme la variable IFS pour le shell…) :) Tu as bien un seul séparateur, et c’est là sa différence, le séparateur n’est plus un seul caractère-délimiteur mais une expression rationnelle (soit [:blank:]…)
C’est à cause de ce traitement plus coûteux que cet utilitaire n’a pas simplement remplacé les autres : chacun répond à des besoins différents, malgré la ressemblance de prime abord.

• awk -F ' ' '{print $3}' (on utilise comme séparateur de champs, le caractère espace, et non la regexp par défaut) devra te donner le même résultat que cut -d ' ' -f 3
• awk -F ':' '{print $1}' devra te donner le même résultat que cut -d ':' -f 1

Ressemblance de prime abord parce-que AWK ont prévu aussi qu’on puisse personnaliser à la sortie/affichage les séparateurs de champs (valeur de OFS qui est par défaut l’espace unique) et d’enregistrement (valeur de ORS qui est par défaut le saut de ligne)

• awk -F '|' '{print $2,$4}' va, par défaut, afficher les deux champs séparés par une espace… tandis que cut -d '|' -f 2,4 va garder le même séparateur (et il n’est pas prévu de changer cela par défaut sauf en enchainant avec un tr '|' ' ' par exemple.)
• awk -F ' ' '{print $3,$1}' va bien nous sortir successivement les troisièmes et premiers champs… tandis que cut -d ' ' -f 3,1 est pareil à cut -d ' ' -f 1,3 car les champs ne sont pas réordonnés…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Arf, j’aurais du vérifier avant d’écrire une connerie ^^ En c’est POSIX et il me semble l’avoir déjà rencontré mais bon mon refus des implicites doit faire que j’oublie chaque fois.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Dans tous les cas, l’affectation a un coût (certes négligeable) ; et si tu ne le ressens pas dans ton programme compilé ce sera plutôt du aux optimisations… (où le compilateur aura probablement généré le même code en détectant qu’il y a une affectation inutile.) :)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Tu m’apprends qu’on n’a pas besoin d’indiquer un délimiteur. Et que cut se débrouille.

Je n’ai pas compris cela, et si c’était l’intention bah c’est faux : il y a une valeur par défaut, la tabulation, quand on n’indique pas de délimiteur. No magic, RTFM.

on peut faire un cut en mettant une tabulation (en utilisant Ctrl+v),

Comme ton script est en bash, tu peux utiliser cut -d $'\t' comme mentionné par un autre commentaire. Mais bon, comme c’est le délimiteur par défaut, pas besoin de s’embêter…
Par contre, oui :

on ne peut pas faire un cut -d"\n"

It's not a bug, that's by design …pour la simple et bonne raison que la commande opère sur les lignes…

mais dans un script je trouve ça pas terrible. Et je crois que j’ai bêtement crû que c’était une suite d’espaces…

C’est hélas un souci courant (pas du tout propre aux scripts shell.) Mon éditeur est toujours configuré pour distinguer visuellement les simples espaces des tabulations.
Dans le cas présent, on pouvait se douter qu’il s’agit de tabulation (ou d’une erreur qui ne va pas fonctionner) car le délimiteur doit être un caractère !

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Parmi les remarques, aucun commentaire n’a tilté sur la première ligne qui m’a bloquée perso

test "${1}" || { echo -e "\nUsage: ${0} <file>\n"; exit 1; }

Il manque l’option du type de test fait, qui je devine est de savoir s’il y a un argument ?

test -n "${1}" || { echo "Usage: ${0} <file>"; exit 1; }
# ou alternativement
test -z "${1}" && { echo "Usage: ${0} <file>"; exit 1; }
# voire encore
test $# -lt 1 && { echo "Usage: ${0} <file>"; exit 1; }
# ou je pense
test $# -ge 1 || { echo "Usage: ${0} <file>"; exit 1; }

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Imposer un DNS menteur, n’est-ce pas faire du Kim ?

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

C’est surprenant qu’à notre époque, les associations étant supposées réunir/associer les gens se sentent obligées de passer par des plateformes qui isolent dans des bulles en plus de contrôler vos vies. Les humains sont paradoxaux.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

t’es genre ovs ?

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

J‘ai plutôt compris qu’on se préoccupe des procédures des événements isolément, mais pas de la méga procédure d’ordonnancement…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

De plus, le lien pointé ne dit pas non catégoriquement mais juste : peut-être bien que oui, peut-être bien que non… Mais visiblement Madeiros n’a pas écouté pas plus qu’il ne fera cas des liens de vulgarisation suivants :

• https://thechosen.fr/jesus-a-t-il-existe/
• https://www.youtube.com/watch?v=6vasbjzv34M

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

(et quand fut venu mon tour, il n’y avait plus de journaliste pour dénoncer)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Merci.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Les épisodes sont régulièrement disponibles sur linuxfr.org, avec une étiquette idoine.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

…pour retirer la clef utm_source et sa valeur.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Attention qu’il s’agissait de la victoire des intras sur les hôtes extras… C’est vrai que c’est à double versant cette lettre ;-)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Si, si, il s’agit bien du téléchargement fait par le Make sans qu’on puisse garantir quoi que ce soit.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Pour ma part, pas vu…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Idée de journal pour aider ton avancement : les karmapaliers.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

https://ferrous-systems.com/blog/ferrocene-update/

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

C'est important l'impression… (en vrai, par rapport aux certifications et autres, c'est bien pour ces boîtes de montrer que c'est ok de leur côté …là en déportant la responsabilité chez les usagers)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Oui, il a beaucoup de fonctionnalités mais un peu moins ; et surtout j'avais trouvé l'ensemble plus léger à l'utilisation —ça ne veut pas dire que c'est léger dans l'absolu, juste plus léger que GitLab. J'ai déjà le serveur de bases qui tourne donc ça change pas beaucoup pour moi.
Après, par méfiance pour le tout intégré (et qu'on ne sait pas migrer d'une solution à une autre), je me dis que Trac pour les tickets et Gogs pour s'interfacer aux dépôts peut être un bon choix.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Arf, en plus git --horror …ce devrait être juste man git …mais ma version a auto-retiré cette option (bien que je ne pense pas avoir atteint la perfection)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume