• [^] # Re: dialog

    Posté par . En réponse au journal choose, pour des scripts shells interactifs. Évalué à 2.

    J'ai souvenir d'avoir écrit un script shell qui exécutait des requêtes SQL dans mariadb pour récupérer les valeurs qui peuplaient des listes, et permettre la configuration de cette même DB. Même s'il est vrai que je n'avais pas vu (ou mal compris plus probablement) l'option --stdout je me souviens que le code était assez horrible à écrire (mais je n'ai pas de regret, cet outil a vraiment aidé le tech qui intervenait sur les machines).

    Ce que tu montres est d'ailleurs assez symptomatique: ton contenu est statique, hard-codé, et pourtant ça sent déjà le souffre, avec ces redirections (qui sont inutiles du coup) et des valeurs de taille "aléatoires".

    De manière générale, je pense que dialog gagnerait a recevoir un gros coup de jeune. Et si on pouvais au passage avoir plusieurs backends hé bien ça ne serait pas plus mal (un backend printf/scanf permettrait d'automatiser des tests, des backends X11/wayland/framebuffer permettrait d'avoir un truc acceptable pour des utilisateurs et non juste pour une personne qui fait la config ou le déploiement d'un logiciel...). Mais bon, yaka fokon. En attendant, dialog fonctionne pour les cas complexes, même si des gens préfèreront choose pour des cas plus simples.

    Pour reprendre ton exemple, à priori cela donnerait:

    INPUT=$(choose -cr "Entrée 1" "Entrée 2" "Entrée 3" )
    echo -e "\nValeur retournée : '$INPUT'"
    

    La différence est claire, je pense. Reste qu'a vue de nez, choose ne supporte pas les tags, qui sont quand même bien pratiques, parce que ça permets d'associer un truc facile à comparer dans le code avec un texte facile à lire pour l'utilisateur final.