getopt, getopts o análisis manual: ¿qué debo usar cuando quiero admitir opciones cortas y largas?

Actualmente estoy escribiendo un script Bash que tiene los siguientes requisitos:

• debería ejecutarse en una amplia variedad de plataformas Unix / Linux
• debería admitir opciones cortas y largas (GNU)

Sé que getoptssería la forma preferida en términos de portabilidad, pero AFAIK no admite opciones largas.

getoptadmite opciones largas, pero BashGuide recomienda enfáticamente que no lo haga :

Nunca use getopt (1). getopt no puede manejar cadenas de argumentos vacías o argumentos con espacios en blanco incrustados. Por favor, olvide que alguna vez existió.

Por lo tanto, todavía existe la opción de análisis manual. Esto es propenso a errores, produce bastante código repetitivo y necesito manejar los errores por mí mismo (supongo getopt(s)que los manejo de errores por sí mismos).

Entonces, ¿cuál sería la opción preferida en este caso?

Si tiene que ser portátil para una gama de Unices, debería atenerse a POSIX sh. Y AFAIU allí no tiene más remedio que manejar el argumento a mano.

getoptvs getoptsparece ser un problema religioso. En cuanto a los argumentos getopten contra en las preguntas frecuentes de Bash :

• " getoptno se pueden manejar cadenas de argumentos vacías" parece referirse a un problema conocido con argumentos opcionales , que parece que getoptsno es compatible en absoluto (al menos al leer help getoptsBash 4.2.24). De man getopt:

  getopt (3) puede analizar opciones largas con argumentos opcionales que reciben un argumento opcional vacío (pero no puede hacer esto para opciones cortas). Este getopt (1) trata los argumentos opcionales que están vacíos como si no estuvieran presentes.

No sé de dónde getoptviene el " no puede manejar [...] argumentos con espacios en blanco incrustados", pero probémoslo:

• test.sh:

  #!/usr/bin/env bash
  set -o errexit -o noclobber -o nounset -o pipefail
  params="$(getopt -o ab:c -l alpha,bravo:,charlie --name "$0" -- "$@")"
  eval set -- "$params"
  
  while true
  do
      case "$1" in
          -a|--alpha)
              echo alpha
              shift
              ;;
          -b|--bravo)
              echo "bravo=$2"
              shift 2
              ;;
          -c|--charlie)
              echo charlie
              shift
              ;;
          --)
              shift
              break
              ;;
          *)
              echo "Not implemented: $1" >&2
              exit 1
              ;;
      esac
  done

• correr:

  $ ./test.sh -
  $ ./test.sh -acb '   whitespace   FTW   '
  alpha
  charlie
  bravo=   whitespace   FTW   
  $ ./test.sh -ab '' -c
  alpha
  bravo=
  charlie
  $ ./test.sh --alpha --bravo '   whitespace   FTW   ' --charlie
  alpha
  bravo=   whitespace   FTW   
  charlie

Me parece un jaque y un compañero, pero estoy seguro de que alguien me mostrará cómo entendí mal la oración. Por supuesto, el problema de la portabilidad sigue en pie; tendrá que decidir cuánto tiempo vale la pena invertir en plataformas con un Bash antiguo o sin Bash disponible. Mi propio consejo es utilizar las pautas de YAGNI y KISS : desarrolle solo para aquellas plataformas específicas que sabe que se utilizarán. La portabilidad del código Shell generalmente llega al 100% a medida que el tiempo de desarrollo llega al infinito.

Existe este getopts_long escrito como una función de shell POSIX que puede incrustar dentro de su script.

Tenga en cuenta que Linux getopt(from util-linux) funciona correctamente cuando no está en modo tradicional y admite opciones largas, pero probablemente no sea una opción para usted si necesita ser portátil a otros Unices.

Las versiones recientes de ksh93 ( getopts) y zsh ( zparseopts) tienen soporte incorporado para analizar opciones largas que podrían ser una opción para usted, ya que están disponibles para la mayoría de los Unices (aunque a menudo no están instaladas de manera predeterminada).

Otra opción sería usar perly su Getopt::Longmódulo, que debería estar disponible en la mayoría de los Unices hoy en día, ya sea escribiendo todo el script perlo simplemente llamando a perl solo para analizar la opción y alimentar la información extraída al shell. Algo como:

parsed_ops=$(
  perl -MGetopt::Long -le '

    @options = (
      "foo=s", "bar", "neg!"
    );

    Getopt::Long::Configure "bundling";
    $q="'\''";
    GetOptions(@options) or exit 1;
    for (map /(\w+)/, @options) {
      eval "\$o=\$opt_$_";
      $o =~ s/$q/$q\\$q$q/g;
      print "opt_$_=$q$o$q"
    }' -- "$@"
) || exit
eval "$parsed_ops"
# and then use $opt_foo, $opt_bar...

Vea perldoc Getopt::Longqué puede hacer y en qué se diferencia de otros analizadores de opciones.

Cada discusión sobre este asunto resalta la opción de escribir el código de análisis manualmente, solo entonces puede estar seguro de la funcionalidad y portabilidad. Le aconsejo que no escriba código que pueda haber generado y regenerado mediante generadores de código abierto fáciles de usar. Use Argbash , que ha sido diseñado para proporcionar la respuesta definitiva a su problema. Es un generador de código bien documentado disponible como una aplicación de línea de comandos , en línea o como una imagen de Docker .

Aconsejo contra las bibliotecas de bash, algunas de ellas usan getopt(lo que hace que sea bastante inportable) y es difícil agrupar un blob de shell ilegible gigantesco con su script.

Puede usarlo getopten sistemas que lo admitan y usar una alternativa para sistemas que no lo admiten.

Por ejemplo, pure-getoptse implementa en Bash puro para ser un reemplazo directo de GNU getopt.