Estilo de opciones de línea de comando - POSIX o qué?

En algún lugar vi una protesta contra java / javac supuestamente usando una mezcla de Windows y estilo Unix como

java -classpath ... -ea ... Something

En mi humilde opinión, no es una mezcla, es como findfunciona también, ¿no? AFAIK, según POSIX, la sintaxis debería ser como

java --classpath ... --ea ... Something

y -abcdefsignificaría especificar 6 opciones cortas a la vez. Me pregunto qué versión lleva en general a menos tipeo y menos errores.

Estoy escribiendo una pequeña utilidad en Java y en ningún caso voy a usar el estilo de Windows /a /bya que estoy interesado principalmente en Unix. ¿Qué estilo debo elegir?

Puede encontrar las convenciones de argumentos POSIX en el capítulo Convenciones de utilidad . El estilo POSIX consta de opciones con un solo guión seguido de una sola letra que indica la opción, con el valor del argumento separado de la opción por un espacio.

Hay excepciones a las reglas find, por ejemplo, pero se deben a los precedentes históricos de Unix.

El X Windows (X11) usa findopciones de nombre largo, como un solo guión.

Las opciones de nombre largo de doble guión fueron desarrolladas por GNU (después de un desvío usando +como prefijo).

Vea esta pregunta de StackOverflow para una discusión de la amplia variedad de sistemas conocidos de manejo de argumentos de línea de comando: hay muchos. ( Dado que esto fue escrito, los poderes fácticos decidieron que la pregunta SO 367309 no era una buena opción para SO. He transferido la respuesta a otra pregunta, ¿Cuál es la sintaxis general de un comando de shell de Unix? ) .

Puede ampliar la lista de técnicas para cubrir git(y una serie de otros sistemas) donde obtiene una estructura como:

• basecommand [ opciones globales ] subcommand[ opciones de subcomando ] [nombre ...]

Puede haber muchos subcomandos, cada uno con su propio léxico de opciones.

Por supuesto, Windows usa una barra inclinada (usada) ' /' para indicar opciones en lugar de guión ' -'.

JCL (para z / OS y OS / 360, y sistemas intermedios) tiende a usar parámetros posicionales separados por comas, y generalmente se considera que no es fácil de usar o una buena interfaz.

EDITAR: Se ha señalado que este estilo es un GNU-ismo, y que los Unix no basados ​​en GNU tienden a usar una sintaxis de un solo guión (en particular, las variantes OS X y BSD).

A pesar de su estado de GNU-ismo, muchos programas de estilo Unix recientemente escritos usan este estilo:

• --long-option para nombres largos de opciones,
• -s para opciones cortas (un caracter),
• -abc para múltiples opciones cortas sin argumentos (un carácter por opción).
• Opciones con argumentos:
  • --long arg o --long=arg para opciones largas,
  • -s arg, -sargu (opcionalmente) -s=argpara opciones cortas. Esto se puede combinar con otras opciones cortas, siempre que solo la última tenga un argumento.
• La misma opción "semántica" puede tener varios alias, más comúnmente uno corto (más rápido de escribir) y uno largo (más fácil de recordar).

Cualquiera que haya usado un shell de Linux por un período de tiempo debería estar familiarizado con este estilo ¹ , por lo que tiene el principio de la menor sorpresa. Permitir la agrupación de múltiples opciones cortas sin ser ambiguo con las opciones largas también es bueno.

¹ Por ejemplo, algunos de los programas que utilizan este estilo (en mi máquina Linux): ls, grep, man, sed, bash, etc ( EDIT: estos son aparentemente GNU-ismos embargo, las máquinas BSD y OS X no utilizan este estilo)

Hay varias bibliotecas que pueden encargarse de analizar esto por usted (la más conocida es la implementación de getopt de GNU ), solo necesita que especifique qué opciones largas y cortas existen, si toman un argumento y qué hacer cuando un se encuentra la opción (Y, por supuesto, qué hacer para los argumentos posicionales, es decir, aquellos que no comienzan -y no son argumentos para las opciones anteriores)

findes un programa muy antiguo (o quizás más probable: una versión reescrita de un programa muy antiguo) que no se puede cambiar fácilmente para usar una nueva sintaxis de línea de comando. Se romperían demasiados scripts y se quejarían demasiados usuarios acostumbrados a la sintaxis anterior. javacprobablemente fue influenciado por gccy amigos, que también siguen una sintaxis antigua por razones históricas.

• El argumento con dash-dash ( --long-arg) es una convención de GNU (vea su implementación de getopt ).
• Los comandos POSIX nunca usan argumentos de doble guión. Esto se aplica a la mayoría de las variantes de Unix (Mac OS X, BSD), excepto Linux, que utiliza GNU de forma predeterminada.

Para su proyecto Java, es posible que desee consultar GNU getopt para Java o Apache CLI . Apoyan ambas convenciones.

Una tercera opción es usar argumentos Java VM y dejar que el tiempo de ejecución los analice por usted:

 $ java -Dcolor=blue

Y luego, en código:

 System.getProperty("color");

Personalmente, usaría el -Didioma y envolvería el encantamiento de Java en un script de shell que maneja el análisis de la línea de comandos, incluida la comprobación de classpath, etc. Esto también facilita a los usuarios nativos ejecutar su programa Java.

Depende. Personalmente prefiero el estilo POSIX, pero en su caso probablemente apuntaría a la coherencia con el entorno en el que se utilizará su herramienta. Esto significa utilizar la convención Java para JAR (a menos que planee tener un script de envoltura que lo haga parecer un comando típico de Unix).