¿Las opciones de la línea de comando toman un signo igual entre el nombre y el valor de la opción?

¿Las opciones de la línea de comando toman un signo igual entre el nombre y el valor de la opción?

Solo usando kubectlcomo ejemplo, observo que

kubectl run --image nginx ...

y

kubectl run --image=nginx ...

ambos trabajan.

Para los programas de línea de comandos en general, ¿existe una regla sobre si se permite/requiere un signo igual entre el nombre de la opción y el valor?

Respuesta1

En general, la implementación de cómo se interpretan los argumentos de la línea de comandos queda completamente a discreción del programador.

Dicho eso,en muchos casos, el valor de una opción "larga" (como la que se introduce con --option_name) se especifica con un =entre el nombre de la opción y el valor (es decir, --option_name=value), mientras que para las opciones de una sola letra es más habitual separar la bandera y el valor con un espacio. , como -o value, o no utilizar ninguna separación (como en -oValue).

Un ejemplo de la página de manual de la utilidad de fecha GNU:

  -d, --date=STRING
        display time described by STRING, not 'now'
  -f, --file=DATEFILE
        like --date; once for each line of DATEFILE

Como puede ver, el valor estaría separado por un espacio del interruptor de opción cuando se usa la forma "corta" (es decir -d), pero por un espacio =cuando se usa la forma "larga" (es decir --date).

Editar

Como señaló Stephen Kitt, elEstándar de codificación GNUrecomienda el uso de getopty getopt_longpara analizar las opciones de la línea de comandos. La página de manual de getopt_longlos estados:

Una opción larga puede tomar un parámetro de la forma --arg=paramo --arg param.

Entonces, un programa que use esa función aceptará ambas formas.

Respuesta2

Para los programas de línea de comandos en general, ¿existe una regla sobre si se permite/requiere un signo igual entre el modificador y el valor?

No, no lo hay. Hay muchos estándares que compiten en el mundo del código abierto y la informática en general (obligatorio xkcd) y todos pueden proponer nuevas reglas y estándares en cualquier momento que quieran. Sintaxis del argumento de utilidad POSIX por ejemplo no menciona =nada por ejemplo mientrashombre optelo menciona. En la práctica puedes encontrarte con todo tipo de programas de línea de comandos:

Aquellos que toman valor de opción largo después =o después de un espacio en blanco:

$ touch a b c d
$ ls --format=verbose
total 0
-rw-r--r-- 1 ja users 0 Mar 17 14:39 a
-rw-r--r-- 1 ja users 0 Mar 17 14:39 b
-rw-r--r-- 1 ja users 0 Mar 17 14:39 c
-rw-r--r-- 1 ja users 0 Mar 17 14:39 d
$ ls --format verbose
total 0
-rw-r--r-- 1 ja users 0 Mar 17 14:39 a
-rw-r--r-- 1 ja users 0 Mar 17 14:39 b
-rw-r--r-- 1 ja users 0 Mar 17 14:39 c
-rw-r--r-- 1 ja users 0 Mar 17 14:39 d

Aquellos que no toman un valor de opción largo después =pero requieren un espacio en blanco:

$ readelf  -a main | grep  'program interpreter'
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
$ patchelf --set-interpreter=fake main
patchelf: getting info about '--set-interpreter=fake': No such file or directory
$ patchelf --set-interpreter fake main
$ readelf  -a main | grep  'program interpreter'
      [Requesting program interpreter: fake]

Aquellos que toman valor después =pero no toman opciones con -o --:

dd if=/dev/urandom of=~/Desktop/test.txt bs=1M count=3

Puede haber muchas razones por las cuales un determinado programa de línea de comandos acepta entradas de una manera determinada: la visión del autor, porque a nadie le importa, porque el autor no sabía que alguien más ya había creado un estándar, porque el programa ha sido portado a Unix de diferentes sistemas operativos con convenciones completamente diferentes ose ha hecho para que parezca que ha sido.

información relacionada