Guiones simples `--` para opciones de un solo carácter, pero guiones dobles` --` para palabras?

¿De dónde vino la convención de usar guiones simples para letras y guiones dobles para palabras y por qué se sigue usando?

Por ejemplo, si escribo ls --help, ves:

  -a, --all                  do not ignore entries starting with .
  -A, --almost-all           do not list implied . and ..
      --author               with -l, print the author of each file
  -b, --escape               print octal escapes for nongraphic characters
      --block-size=SIZE      use SIZE-byte blocks
  -B, --ignore-backups       do not list implied entries ending with ~
...

Intenté buscar en Google - and -- conventionincluso con citas con poco éxito.

En The Art of Unix Programming, Eric Steven Raymond describe cómo evolucionó esta práctica:

En la tradición original de Unix, las opciones de línea de comandos son letras simples precedidas por un guión único ... El estilo original de Unix evolucionó en los teletipos lentos ASR-33 que hicieron de la terquedad una virtud; así las opciones de una letra. Mantener presionada la tecla Mayús requiere un esfuerzo real; por lo tanto, la preferencia por minúsculas y el uso de "-" (en lugar del quizás más lógico "+") para habilitar las opciones.

El estilo GNU utiliza palabras clave opcionales (en lugar de letras de palabras clave) precedidas por dos guiones. Evolucionó años después cuando algunas de las utilidades GNU más elaboradas comenzaron a quedarse sin teclas de opción de letra única ( esto constituyó un parche para el síntoma, no una cura para la enfermedad subyacente ). Sigue siendo popular porque las opciones de GNU son más fáciles de leer que la sopa de letras de los estilos más antiguos. ¹

[1] http://www.faqs.org/docs/artu/ch10s05.html

Una razón para continuar usando las opciones de una sola letra es porque se pueden unir: ls -ltres mucho más fácil de escribir que ls --sort=time --reverse --format=long. Hay varias veces que ambos son buenos para usar. En cuanto a la búsqueda de este tema, intente con la "convención de opciones de línea de comandos de Unix".

La cita de Raymond de @jasonwryan tiene información útil, pero comienza en el medio de la historia:

• Tenga en cuenta que Unix comenzó como una versión de alcance reducido de Multics, y que a lo largo de su historia, las características en Unix fueron a menudo imitaciones o adaptaciones de características vistas y utilizadas en otros sistemas.
• El '-'carácter de opción se usó en Multics. Bitsavers tiene un manual para sus comandos de usuario .
• Otros sistemas utilizaron diferentes caracteres, algunos con más pretensiones de ser más eficientes al presionar teclas (como los que se '/'usan para TOPS y VMS) y otros menos (como los que se '('usan en VM / SP CMS).
• Las opciones de multics eran de varios caracteres, por ejemplo, palabras clave separadas por guiones bajos.
• Las opciones de Multics más largas con frecuencia tenían una forma abreviada más corta, como -printvs -pr(página 3-8).
• Las opciones de Unix eran de un solo carácter, y después de varios años, getoptse introdujo. Debido a que no era parte del Unix original, hay utilidades que no se usaron getopty se dejaron como están. Pero haber getoptayudado a hacer que los programas sean consistentes.

Por otro lado, las opciones de Unix usando getopteran de un solo carácter. Otros sistemas, en particular todos los más grandes, usaban palabras clave. Algunos (no todos) permitieron abreviar esas palabras clave , es decir, no se proporcionaron todos los caracteres siempre que la opción no fuera ambigua. Hay dificultades en esa prueba de ambigüedad. Por ejemplo:

• A principios de 1985, estaba trabajando en un programa que tenía que ser portado a PrimOS . Los desarrolladores de Prime compitieron con varias otras compañías al ofrecer un lenguaje de comandos que (intentó) imitar a cada uno de esos otros, proporcionando los comandos más utilizados de cada uno. Por supuesto, admitieron abreviaturas (al igual que VMS). Después de leer la ayuda en línea, escribí sta, pensando en obtener status. Esa fue la abreviatura de start, y al no haber dado nada para comenzar , el intérprete de comandos me desconectó.
• El X Toolkit (utilizado por xterm ) permite opciones abreviadas. Para usar esto efectivamente en xterm, tiene que preprocesar los parámetros del comando para preferir -v(para la versión) sobre -vb(campana visual). X Toolkit no tiene una forma directa de especificar una opción preferida cuando existe una ambigüedad.

Debido a este potencial de ambigüedad, algunos desarrolladores prefieren no permitir abreviaturas. Lynx , por ejemplo, utiliza opciones de varios caracteres sin permitir abreviaturas.

No todos los programas utilizados getopt: tary psno lo hicieron. Tampoco rcs(o sccs), como puede ver al observar dónde el guión era opcional, y los valores de las opciones eran opcionales.

Teniendo todo esto en cuenta, los desarrolladores de GNU adaptaron las opciones de palabras clave utilizadas en otros sistemas extendiéndose getoptpara proporcionar una versión larga de cada opción corta. Por ejemplo, el registro de cambios de textutils 1.0 dice

Tue May  8 03:41:42 1990  David J. MacKenzie  (djm at abyss)

        * tac.c: Use regular expressions as the record boundaries.
        Give better error messages.
        Reformat code and make it more readable.
        (main): Use getopt_long to parse options.

El cambio en fileutils fue anterior:

Tue Oct 31 02:03:32 1989  David J. MacKenzie  (djm at spiff)

        * ls.c (decode_switches): Add long options, using getopt_long
        instead of getopt.

y alguien puede encontrar uno aún antes, pero parece que el encabezado del archivo muestra la fecha más temprana:

/* Getopt for GNU.
   Copyright (C) 1987, 1989 Free Software Foundation, Inc.

que es (por ejemplo) concurrente con el X Toolkit (1987). La mayoría de las utilidades de Unix con las que está familiarizado (como ls, por ejemplo ps) usaban las opciones existentes de un solo carácter que requieren visitas periódicas al manual. Al presentar getopt_long, los desarrolladores de GNU no hicieron esto al agregar primero nuevas opciones; que comenzaron por la tabulación de las opciones existentes y proporcionar una opción a largo juego.

Debido a que se estaban agregando a un repertorio existente, existía (nuevamente) el problema del conflicto con las opciones existentes. Para evitar esto, cambiaron la sintaxis, usando dos guiones antes de las opciones largas.

Estos programas continúan utilizándose getopt_longde esta manera por los motivos habituales:

• los guiones dependen de las opciones; los desarrolladores no están ansiosos por romper los scripts
• hay un estándar de codificación escrito (que puede ser efectivo)
• a nadie se le ocurrió un conjunto de herramientas de la competencia que sea notablemente incompatible (tanto los desarrolladores BSD como GNU copian los nombres de las opciones entre sí)

En la interfaz de línea de comandos de Wikipedia se informa:

En sistemas similares a Unix, el guión ASCII menos se usa comúnmente para especificar opciones. El carácter suele ir seguido de una o más letras. Un argumento que es un solo guión, menos por sí mismo sin letras, generalmente especifica que un programa debe manejar los datos que provienen de la entrada estándar o enviar datos a la salida estándar. Se usan dos guiones – menos caracteres (-) en algunos programas para especificar "opciones largas" donde se usan nombres de opciones más descriptivos. Esta es una característica común del software GNU.

Supongo que se deseaban opciones más descriptivas y también con opciones más largas no tendrá que preocuparse por quedarse sin opciones de un solo carácter.

Una vez que decida que desea opciones largas, entonces tiene un problema, al menos si planea admitir opciones largas y cortas. No soy positivo, pero creo que la respuesta de Arcege tiene la clave de por qué - y -. Una rutina de procesamiento genérico, por ejemplo. getopt_long (), necesitaría saber si un solo argumento de línea de comando podría contener múltiples opciones, por ejemplo. -ltr. Por lo tanto, una rutina de procesamiento debería ser capaz de diferenciar entre los dos. Si leo un solo guión, -, entonces el resto del argumento de la línea de comando puede coincidir con múltiples opciones. Si leo un guión doble, -, entonces el resto del argumento de la línea de comando debe coincidir con una sola opción.

Recientemente utilicé getopt_long () y estoy empezando a gustarme las opciones largas, ya que son más fáciles de recordar y de documentar. Si tengo los siguientes dos comandos:

./aggregator -f 15

./aggregator --flush-time 15

Yo diría que el segundo que usa la opción larga es más autoexplicativo.

Probablemente hay algunas razones por las que se utilizan los dos métodos. Uno, por supuesto, es la tradición. Los programadores y usuarios son humanos, y los humanos esperan que las cosas funcionen de cierta manera. Si no hay razón para cambiar (y realmente, para una línea de comando, no hay muchas razones para cambiar), entonces no lo haga.

Dicho esto, sé que existen herramientas que usan el guión único para una opción larga, o incluso eliminan los guiones por completo. Estas herramientas pueden ser difíciles al principio y tienden a sobresalir como verrugas en un sistema unificado de otro modo.

Cuando estaba aprendiendo la diferencia entre los dos (y antes de que se convirtiera en una segunda naturaleza), siempre recordaba que el guión "corto" coincide con las opciones "cortas", mientras que el guión "largo" (o doble) coincide con el "largo" opciones. No sé si ese razonamiento se utilizó en el desarrollo del estilo de doble guión, pero es una posibilidad.