Journal Yb : venez tester le parser YAML en bash

Posté par  . Licence CC By‑SA.
Étiquettes :
14
20
juil.
2023

Lorsque j'étais venu vous présenter loco.sh il y a quelques mois, l'utilisation de YAML avait fait débat. À l'époque il n'y avait pas de solutions de parsing complète pour YAML en bash.

Après de nombreuses difficultés à trouver à la fois une solution performante et portable, j'ai décidé de développer yb.

Yb c'est un parser YAML développé en bash, qui s'appuie sur des techniques modernes de programmation pour être un minimum performant.

Je viens tout juste de finaliser l'implémentation de l'option -r qui permet de supprimer des clés dans les fichiers YAML. Je vous invite donc à aller voir le repo et me faire vos retours, surtout vos bugs !

https://gitlab.com/t0pd4wn/yb

  • # YAML, je ne pratique pas, mais…

    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 21 juillet 2023 à 07:44.

    …après une rapide recherche, j'ai dégotté :

    • yq, écrit en Go, qui ambitionne d'être à YAML ce que jq est à JSON ;
    • yq, écrit en Python, qui convertit YAML en JSON et inversement pour un traitement par le même jq.

    Question portabilité et performance, par rapport à du Bash, ça se pose là quand même…

    Contre les effets néfastes des jeux vidéos et des médias sociaux sur nos enfants : Zelbinium

  • # C'est une révolution

    Posté par  . Évalué à 7.

    On a enfin les outils pour être aussi efficace qu'avec le XML !

  • # Limitations

    Posté par  . Évalué à 6.

    Il me semble qu'yb a beaucoup de limitations. Par exemple avec le fichier :

    # file: example.yaml
    foo: |
      bar
      bar

    et la commande :

    yq -f example.yaml -k foo

    Je m'attends à avoir ma chaine sur une double ligne :

    bar
    bar
    

    Et pas mon pipe…

    Ne pas gérer les fonctionnalités plus complexes comme les références me semble être une utilisation avancée, mais pour ce qui est des chaines de caractères multiligne c'est l'une des fonctionnalités très utilisées de yaml.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Pourquoi pas en brainfuck ?

    Posté par  (site web personnel) . Évalué à -5.

    Quitte à écrire un truc inutile et impossible à maintenir…

    • [^] # Re: Pourquoi pas en brainfuck ?

      Posté par  . Évalué à 2. Dernière modification le 21 juillet 2023 à 16:41.

      Sympathique comme message

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # c'est quoi ?

    Posté par  . Évalué à 8.

    des "des techniques modernes de programmation pour être un minimum performant." ? Tu peux détailler ?

  • # les réponses

    Posté par  . Évalué à 2. Dernière modification le 22 juillet 2023 à 16:36.

    Merci pour ces retours !

    • syntaxe spécialisée : yb devrait supporter prochainement "|" et ">" ; par ailleurs, il ne me semble pas que yq supporte une option -k ;)
    • techniques BASH : principalement des méthodes de parsing de string et quelques subtilités pour rendre le code plus rapide et dynamique (actuellement assez peu optimisé)

    à bientôt pour la V1.0 !

  • # c'est pas yaml ;)

    Posté par  . Évalué à 4.

    y'a des bug, typiquement les no ne sont pas transformé en false :D pareil pour les y/n/on/off… et j'en passe. C'est important parce qu'on s'attend a avoir une seule chose à tester, et pas 10 ou 20 pour évaluer une valeur booléenne.

    https://makandracards.com/makandra/24809-yaml-keys-like-yes-or-no-evaluate-to-true-and-false

    Bien évidemment ce n'est pas à convertir si c'est protégé par des quote ;)

    de même les chaines de type 12:42 ne sont pas traduit en 702.

    Donc c'est pas un parser yaml.

    pour tester si on fait bien les conversion on peut regarder là.

    https://yaml-online-parser.appspot.com/

    paysCode:
      norway: no
    codePays:
      no: norway
    
    volMatin: 11:12

    donne en json

    {
      "paysCode": {
        "norway": false
      }, 
      "codePays": {
        "false": "norway"
      }, 
      "volMatin": 672
    }

    pour éviter ces déboires avec le yaml vaut mieux tout quotter;

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: c'est pas yaml ;)

      Posté par  . Évalué à 0.

      Merci pour ce feedback très intéressant. Comme je ne comptais pas traduire vers d'autres langages que YAML, je ne m'étas pas interrogé sur la transformation au regard du typage.

      Peut-être que je devrais réintituler le projet "Yaml reader" ou ajouter une option -T qui supportera le typage. ;)

      • [^] # Re: c'est pas yaml ;)

        Posté par  . Évalué à 3. Dernière modification le 25 juillet 2023 à 12:51.

        y'a pas que le typage, y'a les alias et indirections; yaml est particulièrement compliqué comme langage, contrairement au json.

        par exemple

        root: &plop
          two: [here, and]
          three: {it: updates, in: real-time}
          ampli: yes
        zut:
          tonk: *plop

        donne en json

        {
          "root": {
            "ampli": true, 
            "two": [
              "here", 
              "and"
            ], 
            "three": {
              "it": "updates", 
              "in": "real-time"
            }
          }, 
          "zut": {
            "tonk": {
              "ampli": true, 
              "two": [
                "here", 
                "and"
              ], 
              "three": {
                "it": "updates", 
                "in": "real-time"
              }
            }
          }
        }

        et avec ton script :

        $>./yb -f plop.yaml -k zut.tonk
        *plop
        
        $> ./yb -f plop.yaml -k root
        &plop

        là on est faux; et je dirai même plus problématique; car le seul avantage du yaml par rapport au json, c'est justement cette capacité d'alias; les conversion de clé octales, booléennes sont à s'arracher les cheveux, et ne devraient pas être gérés par le yaml.

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

Suivre le flux des commentaires

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