¿Por qué las aplicaciones de consola comienzan los argumentos con:
a) one dash (myapp -arg1 123; ls -al)
b) two dashes (myapp --arg1 123; git push origin master --force)
c) without dashes at all (myapp 123; man ls)
d) without dashes but with the equal sign (myapp arg1=123; dd if=/dev/zero)
¿No existe una convención estándar? Incluso entre las aplicaciones Linux estándar, los tres casos a), b) yd) existen al mismo tiempo. Y es difícil recordar cuándo debo usar, por ejemplo, -help y cuándo --help.
Respuesta1
Los guiones se utilizan para indicaropciones, que modifican el comportamiento del comando. Los argumentos sin guiones indican los parámetros principales del comando, a menudo son nombres de archivos.
Los guiones simples suelen introducir opciones que constan de una sola letra. Se pueden agrupar varias de estas opciones, por lo que ls -a -lse pueden abreviar como ls -al. Esta era la convención estándar para la mayoría de los primeros comandos de Unix.
Los guiones dobles introducen opciones que son palabras completas. Esta convención es necesaria para distinguirlos de la agrupación descrita anteriormente. Este estilo de opción fue popularizado por las versiones GNU de utilidades, porque a menudo tenían tantas características que se quedaban sin letras mnemónicas individuales.
A veces una opción requiere un parámetro propio. Los estilos de esto varían: algunos comandos usan -o parameter, algunos usan -oparameter, algunos usan --option=parametery algunos permiten múltiples formas.
También hay un puñado de comandos que inventaron sus propios estilos de argumento ideosincrásicos. Por lo general, estos son comandos muy antiguos, anteriores a que hubiera un consenso sobre las convenciones de argumentos. Ejemplos de esto son tary dd. findtambién es inusual por ser un comando antiguo que usaba opciones de palabras completas antes de que --se creara la convención; sus argumentos son prácticamente un lenguaje propio, porque sus necesidades no encajan en el command -options parametersparadigma típico.
Otras razones de la variación entre los comandos es que Unix originalmente no tenía una función de biblioteca de análisis de argumentos. No fue hasta bien entrada su vida que se crearon las funciones getopty . getoptsEl uso de estas bibliotecas esencialmente te obliga a seguir prácticas comunes. Pero los programas más antiguos hacían su propio análisis ad hoc de argumentos y diferentes programadores tomaban decisiones diferentes.
Respuesta2
@Barmar tiene razón, pero le faltan algunos puntos de información. La razón por la que esto realmente sucede es únicamente por cómo se escribió el código del programa y, más específicamente, qué se usó para analizar los argumentos.
Antes de hablar más sobre eso, quiero aclarar algo de terminología. En primer lugar, lo que usted llama "opciones" en realidad también son argumentos. De hecho, todo lo que escribe en la línea de comandos es un argumento (incluido el nombre del programa). Estos argumentos normalmente se almacenan en una matriz (llamada argven C). Luego, el programa elige cómo (o si debe) analizar estos argumentos y comportarse en consecuencia. Ahora bien, los argumentos suelen adoptar una de tres formas:
- banderas (no acepte un argumento; simplemente active o desactive un comportamiento)
- interruptores (tomar un argumento; modificar el comportamiento según el argumento)
- parámetros (datos simples que no pretenden modificar el comportamiento)
1y 2a menudo se les conoce como OPTIONSy están destinados a cambiar el comportamiento del programa, pero ambos aparecen en estilos diferentes (como también lo menciona Barmar). En realidad, la biblioteca de C getoptpermite una gran flexibilidad en esta área. Aunque la convención es que las opciones se especifiquen como una sola letra precedida por un solo guión o una palabra completa precedida por dos guiones, los programas escritos con getoptrealmente permiten que cualquiera de los siguientes sea equivalente (suponiendo que helpse proporcione hcomo índice ):
-h,--h,--help
Sin embargo, -helpen realidad no está permitido getopt(por lo tanto, si una herramienta utiliza -helpsu indicador de uso, puede estar bastante seguro de que no fue escrita con la getoptbiblioteca). Esto se debe a que getoptinterpreta un solo guión para señalar una lista de opciones combinadas, por lo que se interpreta -helpcomo -h -e -l -p.
Además, cuando las opciones toman argumentos (convencionalmente llamados "optargs"), hay algunas formas de especificarlos. Lo siguiente, dado que el índice optes o,y eso optrequiere un optarg¹—son todos también equivalentes:
-oParameter,-o Parameter,--opt=Parameter,--opt Parameter
Aunque la getoptbiblioteca es un estándar ampliamente utilizado ahora, muchas herramientas anteriores a ella (como tar) todavía usan su propia configuración de análisis, por lo que tar -xjfes equivalente a tar xjf.
TL;DR: getoptno siempre ha existido, por lo que los programadores tuvieron que analizar los argumentos a su manera. Pero las herramientas más nuevas suelen utilizarlo para que su comportamiento sea sensato y predecible.
1 Existe una posibilidad no bien documentada de tener opciones para poder optar, pero norequeriruno. Los optargs opcionales causan todo tipo de cosas molestas y hacen que algunas de las formas más comunes de especificar opciones no sean válidas (ya que serían ambiguas). Afortunadamente, los argumentos que toman un argumento opcional no son demasiado comunes.
Respuesta3
Las opciones comienzan con un guión, generalmente una letra, se pueden especificar varias opciones.
ls -l -h
or
ls -lh
Las opciones comienzan con dos guiones, generalmente toman palabras, las opciones múltiples no pueden funcionar.
ls --list --human