Journal Auxilium - Simplifiez le Traitement des Arguments de vos Scripts Shell

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
33
14
juil.
2025

Avant-propos

J'ai déjà publié un petit journal sur cette bibliothèque : linuxfr.org/users/seraf1/journaux/args-parser-pour-shell.
Depuis, le dépôt a déménagé sur Codeberg, et il y a eu quelques petites modifications.

Présentation

Auxilium est une bibliothèque (compatible POSIX) de fonctions pour les scripts Shell, conçue pour simplifier l'analyse des arguments en ligne de commande et la génération automatique de messages d'aide (--help). Elle offre une méthode structurée pour définir des options, des arguments positionnels, des valeurs par défaut, des listes de choix et des fonctions de rappel, tout en prenant en charge la génération de scripts d'auto-complétion.

Ce script n'est pas destiné à être exécuté directement, mais à être "sourcé" (inclus) dans vos propres scripts shell.

Pourquoi utiliser Auxilium.sh ?

Si vous écrivez régulièrement des scripts shell, vous savez que la gestion des arguments peut rapidement devenir complexe et fastidieuse. auxilium.sh s'occupe de cette complexité pour vous, vous permettant de vous concentrer sur la logique principale de votre script.

Fonctionnalités principales

  • Définition facile des arguments : Ajoutez des arguments avec des noms longs (--arg) et des options courtes (-a).
  • Types d'arguments variés : Supporte les chaînes de caractères (str), les options binaires (opt) et les arguments positionnels (positional)..
  • Valeurs par défaut : Définissez des valeurs par défaut pour vos arguments.
  • Listes de choix : Limitez les valeurs possibles pour un argument à une liste prédéfinie.
  • Fonctions de rappel (Callbacks) : Exécutez une fonction spécifique lorsqu'un argument est rencontré ou une fois qu'il est analysé.
  • Gestion des arguments restants : Capturez tous les arguments restants après un argument spécifique.
  • Génération automatique de l'aide (--help) : Créez automatiquement un message d'aide détaillé affichant toutes les options, leurs descriptions, les valeurs par défaut et les choix possibles.
  • Génération d'auto-complétion : Générez des scripts d'auto-complétion pour Bash et Zsh.
  • Nettoyage automatique : Supprime les fichiers temporaires créés par l'utilitaire.

Exemple d'utilisation

Voici un exemple simple pour illustrer comment utiliser Auxilium dans votre propre script :

#!/bin/sh

# Assurez-vous que auxilium.sh est accessible
# Remplacez /chemin/vers/auxilium.sh par le chemin réel
. /usr/share/auxilium/auxilium.sh

# --- 1. Initialisation de l'application ---
auxilium_init "mon_app" -m "Une application d'exemple pour démontrer Auxilium."

# --- 2. Ajout des arguments ---
auxilium_add "fichier_config" -s c -t str -m "Chemin vers le fichier de configuration." -d "/etc/mon_app/config.conf"
auxilium_add "verbeux" -s v -t opt -m "Activer le mode verbeux."
auxilium_add "action" -s a -t str -l "demarrer|arreter|redemarrer" -m "Action à exécuter." -d "demarrer"
auxilium_add "cible" -t positional -m "Cible de l'opération (argument requis)."

# --- 3. Analyse des arguments ---
auxilium_parse "$@"

# --- 4. Accès aux valeurs des arguments ---
echo "Fichier de configuration : ${AUXILIUM_ARG_FICHIER_CONFIG}"
echo "Action à effectuer : ${AUXILIUM_ARG_ACTION}"

if [ "${AUXILIUM_ARG_VERBEUX}" = "1" ]; then
    echo "Mode verbeux activé."
fi

if [ -n "${AUXILIUM_ARG_CIBLE}" ]; then
    echo "Cible de l'opération : ${AUXILIUM_ARG_CIBLE}"
else
    echo "Erreur : Une cible est requise."
    auxilium_usage # Affiche l'aide si un argument positionnel requis est manquant
    exit 1
fi

# --- 5. Nettoyage des fichiers temporaires ---
auxilium_close

Contribuer

Les contributions sont les bienvenues ! N'hésitez pas à forker le dépôt, proposer des améliorations, signaler des bugs ou soumettre des pull requests.

Licence

Ce script est distribué sous la licence Apache 2.0. Consultez le fichier debian/copyright pour plus de détails.

Développé par Philippe SÉRAPHIN

Site web : auxilium.spn109.fr

Dépôt GIT : codeberg.org/spn109/auxilium

  • # Fichiers temporaires

    Posté par  . Évalué à 5 (+3/-0).

    Ça a l'air sympa !

    Mais je suis un peu déçu qu'il y ait besoin de créer des fichiers temporaires juste pour ça. Du coup il faut faire très attention à la façon dont le shell se termine, sinon on risque de laisser des traces derrières. N'y a-t-il pas moyen de s'en passer ?

    • [^] # Re: Fichiers temporaires

      Posté par  (site web personnel) . Évalué à 3 (+2/-0).

      Si l'on veut rester compatible POSIX, il n'y a pas vraiment moyen de s'en passer malheureusement.

      • [^] # Re: Fichiers temporaires

        Posté par  (Mastodon) . Évalué à 4 (+1/-0).

        Si l'on veut rester compatible POSIX

        Au passage, bravo pour ce tour de force !

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Fichiers temporaires

        Posté par  . Évalué à 2 (+1/-0). Dernière modification le 23 juillet 2025 à 10:12.

        Il y a moyen, avec des variables, de la même manière que tes arguments sont définis. Par exemple:

        source.sh:

        #!/bin/sh

parse_init()
{
  ARG_PREFIX="ARG_"
}

parse_args()
{
  n=1
  for arg in "$@"; do
    eval "${ARG_PREFIX}${n}"="$arg"
    n=$((n+1))
  done

  unset ARG_PREFIX # clean up internal var
}

        test.sh:

        #!/bin/sh

. ./source.sh

parse_init
parse_args sans fichier tmp
echo "$ARG_1" "$ARG_2" "$ARG_3"

  • # quid novis?

    Posté par  (site web personnel, Mastodon) . Évalué à 3 (+2/-1).

    Pour les personnes ayant lu et participé au précédent journal, il aurait été bien d’indiquer les nouveautés et les futures fonctionnalités prévues.

    Je profite de ce commentaire pour demander de nous parler aussi de l’histoire (comment et pourquoi est née l’idée, d’où est puisé la motivation) et de l’histoire (difficultés rencontrées, retours d’expérience d’un développement conséquent en shell, etc.)

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

    • [^] # Re: quid novis?

      Posté par  (site web personnel) . Évalué à 8 (+7/-0).

      • Pour ce qui est des modifications, c'est surtout le basculement sur Codeberg. Il y a aussi des petits correctifs de bogues, mais pas de nouvelles fonctionnalités. Celles-ci viendront avec une nouvelle version, notamment avec la prise en charge des sous-commandes (le plus dur dans ce cas étant la génération des fichiers de complétion).
      • Pour l'idée, elle m'est venue à force de faire des scripts shells qui devaient être compatibles POSIX (le boot de Debian se fait avec Dash et non Bash). Le casse-tête pour gérer correctement les arguments m'a convaincu de me lancer dans l'écriture de cette bibliothèque. Une autre contrainte étant qu'il fallait pouvoir définir ces arguments dans plusieurs fichiers sources.
      • La plus grosse difficulté rencontrée pour ce développement reste l'absence de tableaux en Shell POSIX, d'où l'utilisation de fichiers temporaires.
      • Il faut également penser à faire des fonctions, même en Shell, ça aide !
      • Et pour finir, une recommandation pour ceux qui voudraient faire un gros script Shell, utilisez ShellCheck, cela vous évitera de nombreuses prises de tête (une extension VSCodium est disponible).

      • [^] # Re: quid novis?

        Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

        l'absence de tableaux en Shell POSIX, d'où l'utilisation de fichiers temporaires.

        Oh oui, SC3030 …avec parfois de géniales contorsions :D J’avais vu que quelqu’un s’était fait une bibliothèque sympa…

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

        • [^] # Re: quid novis?

          Posté par  (site web personnel) . Évalué à 3 (+2/-0).

          Je ne connaissais pas et je viens de regarder un peu.
          Plutôt que de passer par des fichiers temporaires, il passe par des eval à profusion, c'est une autre façon de faire qui me fait un peu peur au point de vu de la sécurité.

          • [^] # Re: quid novis?

            Posté par  (site web personnel, Mastodon) . Évalué à 6 (+4/-0).

            Oui, les eval c’est quelque chose de délicat et on n’est jamais sûr de bien faire… Le passage par fichier est plus simple et plus sécure si on se repose sur mktemp…
            En général quand je ne peux me passer de tableaux associatifs c’est signe qu’il ne faut pas que j’écrive mon truc en shell :)

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

            • [^] # Re: quid novis?

              Posté par  (site web personnel) . Évalué à 2 (+0/-0).

              Si tu regardes la commande module, c'est une fonction bash (pas le choix si on veut modifier le shell courant) qui fait un eval du résultat de la commande modulecmd. Cette dernière est programmée historiquement en TCL.

              Bref, tu peux tes traitements par exemple en Perl et faire un eval du résultat dans ta fonction Bash. J'ai dis Perl car très stable et c'est quasiment partout…

              • [^] # Re: quid novis?

                Posté par  (site web personnel, Mastodon) . Évalué à 4 (+2/-0).

                Je fais souvent du AWK ou du PERL en standalone ou intégré dans mes scripts shell.
                Les nouvelles générations ne connaissent hélas pas.

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

      • [^] # Re: quid novis?

        Posté par  . Évalué à 2 (+1/-1). Dernière modification le 19 juillet 2025 à 17:12.

        Pour l'idée, elle m'est venue à force de faire des scripts shells qui devaient être compatibles POSIX (le boot de Debian se fait avec Dash et non Bash)

        Je ne comprends pas l'argument du boot avec Dash pour justifier d’écrire un script compatible POSIX. Si le bang précise qu'il faut utiliser bash (#!/usr/bin/bash), le script sera bine exécuté par Bash.

        • [^] # Re: quid novis?

          Posté par  (site web personnel) . Évalué à 4 (+2/-0).

          Si le bang précise

          si bash n'est pas disponible :D par exemple, pour de l'embarqué (genre openwrt — en tout cas à une époque) où tu n'as pas toutes les possibilités. Sur l'OpenBSD pour ton grille-pain, tu n'auras peut-être pas bash…

          • [^] # Re: quid novis?

            Posté par  . Évalué à 3 (+1/-0).

            Là je suis bien d'accord. Mais ici nous sommes dans le contexte d'un script interactif sur une Debian et la justification était que le shell par défaut était Dash.

            • [^] # Re: quid novis?

              Posté par  (site web personnel) . Évalué à 1 (+0/-0).

              Le script n'est pas forcément interactif, il peut s'agir de scripts dont l'installation nécessitent la génération des fichiers de complétion. Dans ce cas, le shebang ne sera pas utilisé (appel de dash -c pour Debian par exemple)

        • [^] # Re: quid novis?

          Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

          Ça peut dépendre aussi de ton parc. J’ai déjà travaillé dans des environnements où tu n’as pas /bin/bash partout… Et l’année dernière j’ai du faire un script pour une structure où il y a du bash partout mais je me suis retrouvé à me battre avec pléthore de versions (développement initialement fait pour la v5 et puis on a découvert qu’il y a beaucoup de v4 et pas mal de v3.0 à 3.3 : j’aurais gagné plus de temps à faire un script POSIX —on en était plus loin à la fin) :D

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

Envoyer un commentaire

Suivre le flux des commentaires

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