Dans les scripts, utilisons les options longues

• De nombreux utilitaires en ligne de commande prennent en charge les options au format court (-f) et au format long (--force)
• Le format court est destiné à un usage interactif ; dans les scripts, il est recommandé d’utiliser le format long
• Par exemple, dans le terminal, on saisit $ git switch -c my-new-branch
• Dans un script de release, on l’écrit ainsi :
  • try shell.exec("git fetch origin --quiet", .{});
  • try shell.exec("git switch --create release-{today} origin/main", .{ .today = stdx.DateUTC.now() }, );
• Les options au format long sont bien plus explicites pour le lecteur

[GN⁺]

Commentaire Hacker News

• Je préfère les options longues, mais lorsqu’il faut invoquer des commandes POSIX de façon portable, les options courtes sont le seul choix possible. POSIX ne spécifie pas d’options longues

  • Par exemple, on peut se référer à la spécification de diff
  • Dans la plupart des cas, utiliser des bindings de bibliothèque est une meilleure alternative que de dépendre d’utilitaires POSIX
  • Au lieu d’appeler grep, utiliser quelque chose comme libpcre peut être plus efficace
  • Pour les utilitaires non POSIX comme git, hg, rg, ag, il est raisonnable d’utiliser des options longues

• Il ne faut pas mélanger l’interpolation de chaînes et l’exécution de commandes

  • Il faut être particulièrement prudent lorsque la commande est traitée via un shell
  • Quel que soit le langage, il faut utiliser une API d’exécution basée sur des listes ou des tableaux afin de transmettre directement les arguments à execv(2), execvp(2), etc.

• Je suis d’accord sur le fait qu’il faut utiliser des options longues, mais il faut tenir compte de la portabilité

  • Toutes les distributions BSD ne prennent pas en charge les options longues de style GNU
  • Si vous voulez de la portabilité, vous devez utiliser des options courtes

• Il ne faut pas oublier d’utiliser -- après toutes les options et avant les arguments dynamiques

• Il faut vérifier avant d’invoquer une commande que sa longueur ne dépasse pas ARG_MAX

  • Par exemple, lorsqu’on a une commande comme celle-ci :
    • grep --ignore-case --files-with-matches -- "hello" *.c
  • Il faut l’appeler comme ceci :
    • CMD="grep --ignore-case --files-with-matches -- \"hello\" *.c"
    • ARG_MAX=$(getconf ARG_MAX)
    • CMD_LEN=${#CMD}
    • if (( CMD_LEN > ARG_MAX )); then
    • echo "Error: Command length ($CMD_LEN) exceeds ARG_MAX ($ARG_MAX)." >&2
    • exit 1
    • fi
    • eval "$CMD" # attention, évalue les noms de fichiers

• Je suis d’accord avec cette approche. Un autre avantage est qu’il devient plus facile de faire un grep dans la page de man pour retrouver ce que fait une option

• Si vous voulez rendre votre script portable vers d’autres systèmes POSIX, vous devrez peut-être utiliser des options courtes

  • Les options longues ne sont pas standardisées
  • À vous de décider du compromis

• Il faut mettre chaque option sur une ligne séparée pour faciliter le suivi et le git blame

• C’est l’une des règles de base quand on écrit des scripts. S’il est possible d’utiliser des options longues, il faut le faire

  • C’est tout simplement trop sensé

• Les options au format long sont bien plus explicites pour le lecteur

  • Il y a moins de risques de fautes de frappe