¿La precedencia de las opciones de comando?

Sé que rm -f file1se eliminará con fuerza file1sin preguntarme.

También sé que rm -i file1primero me preguntará antes de eliminarfile1

Ahora, si ejecuta rm -if file1, esto también se eliminará a la fuerza file1sin preguntarme.

Sin embargo, si ejecuta rm -fi file1, me preguntará antes de eliminar file1.

Entonces, ¿es cierto que al combinar opciones de comando, prevalecerá el último? como rm -if, entonces -ftendrá prioridad, pero rm -fientonces -itendrá prioridad.

El lscomando, por ejemplo, no importa si dijiste ls -latRo ls -Rtal.

Así que supongo que solo importa cuando tienes opciones de comando contradictorias como rm -if, ¿es correcto?

Cuando se usa rmcon ambos -iy -f opciones, se ignorará el primero. Esto está documentado en el estándar POSIX :

    -f
       Do not prompt for confirmation. Do not write diagnostic messages or modify
       the exit status in the case of nonexistent operands. Any previous
       occurrences of the -i option shall be ignored.
    -i
       Prompt for confirmation as described previously. Any previous occurrences
       of the -f option shall be ignored.

y también en la infopágina de GNU :

‘-f’
‘--force’

    Ignore nonexistent files and missing operands, and never prompt the user.
    Ignore any previous --interactive (-i) option.

‘-i’
    Prompt whether to remove each file. If the response is not affirmative, the
    file is skipped. Ignore any previous --force (-f) option.

Veamos qué pasa debajo del capó:

rmprocesa su opción con getopt(3), específicamente getopt_long. Esta función procesará los argumentos de la opción en la línea de comando ( **argv) en orden de aparición:

Si se llama getopt () repetidamente, devuelve sucesivamente cada uno de los caracteres de opción de cada uno de los elementos de opción.

Esta función generalmente se llama en un bucle hasta que se procesen todas las opciones. Desde esta perspectiva de funciones, las opciones se procesan en orden. Sin embargo, lo que sucede realmente depende de la aplicación, ya que la lógica de la aplicación puede elegir detectar opciones en conflicto, anularlas o presentar un error. Para el caso de rmy las opciones iy f, se sobrescriben perfectamente entre sí. De rm.c:

234         case 'f':
235           x.interactive = RMI_NEVER;
236           x.ignore_missing_files = true;
237           prompt_once = false;
238           break;
239 
240         case 'i':
241           x.interactive = RMI_ALWAYS;
242           x.ignore_missing_files = false;
243           prompt_once = false;
244           break;

Ambas opciones establecen las mismas variables, y el estado de estas variables será la última opción en la línea de comando. El efecto de esto está en línea con el estándar POSIX y la rmdocumentación.

Sí, para rmesto es válido. Si la última opción anula a las anteriores, depende del programa individual en sí. Desde 'info rm'

'-f' '--force' Ignora los archivos inexistentes y los operandos faltantes, y nunca pregunta al usuario. Ignora cualquier opción anterior '--interactive' ('-i').

'-i' Pregunta si se debe eliminar cada archivo. Si la respuesta no es afirmativa, se omite el archivo. Ignora cualquier opción anterior '--force' ('-f'). Equivalente a '--interactive = always'.

Como pista general: infogeneralmente es más detallado que man, lo que en sí mismo suele ser más detallado que la --helpopción.

No hay "precedencia" para las banderas, cada programa las maneja como lo desea. La mayoría hace un esfuerzo para recopilar todas las marcas y verificar conflictos, para las herramientas estándar (como las mencionadas rm(1)), los estándares relevantes pueden exigir algo (pero, una vez más, su versión particular puede ser descuidada al interpretar casos de esquina del estándar / no obtener una prueba específica para ellos).

Para el programador que escribe el programa, es más fácil considerar los argumentos (banderas y otros) en estricto orden de izquierda a derecha, y tal vez rescatarlos al tocar algún inconveniente. Si usa una biblioteca para manejar banderas (por ejemplo getopt(3), hay varias versiones flotando), el programador presumiblemente hace lo que resulta más fácil / natural. Los programadores son personas, las personas son flojas (o al menos no les gusta pensar en la explosión combinatoria).