Solo usando kubectl
como 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 getopt
y getopt_long
para analizar las opciones de la línea de comandos. La página de manual de getopt_long
los estados:
Una opción larga puede tomar un parámetro de la forma
--arg=param
o--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.