La precedenza delle opzioni di comando?

So che rm -f file1rimuoverà forzatamente file1senza chiedermi.

So anche che rm -i file1mi chiederà prima di rimuoverefile1

Ora, se lo esegui rm -if file1, anche questo verrà rimosso forzatamente file1senza richiedermi.

Tuttavia, se lo esegui rm -fi file1, mi verrà richiesto prima di rimuoverlo file1.

Quindi è vero che quando si combinano le opzioni di comando, l'ultima avrà la precedenza? come rm -if, quindi -favrà la precedenza, ma -fiallora -iavrà la precedenza.

Il lscomando, ad esempio, non importa se hai detto ls -latRo ls -Rtal.

Quindi immagino sia importante solo quando hai opzioni di comando contraddittorie come rm -if, è corretto?

Quando si utilizza rmcon entrambe -ie le -f opzioni, la prima verrà ignorata. Questo è documentato nello standard 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.

e anche nella infopagina 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.

Vediamo cosa succede sotto il cofano:

rmelabora la sua opzione con getopt(3), in particolare getopt_long. Questa funzione elaborerà gli argomenti delle opzioni nella riga di comando ( **argv) in ordine di apparizione:

Se getopt () viene chiamato ripetutamente, restituisce in successione ciascuno dei caratteri di opzione da ciascuno degli elementi di opzione.

Questa funzione viene in genere chiamata in un ciclo fino a quando non vengono elaborate tutte le opzioni. Da questo punto di vista delle funzioni, le opzioni vengono elaborate in ordine. Ciò che effettivamente accade, tuttavia, dipende dall'applicazione, poiché la logica dell'applicazione può scegliere di rilevare opzioni in conflitto, sovrascriverle o presentare un errore. Nel caso di rme le opzioni ie f, si sovrascrivono perfettamente a vicenda. Da 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;

Entrambe le opzioni impostano le stesse variabili e lo stato di queste variabili sarà qualsiasi opzione sia l'ultima nella riga di comando. L'effetto di questo è in linea con lo standard POSIX e la rmdocumentazione.

Sì, per rmquesto è valido. Se l'ultima opzione ha la precedenza su quelle precedenti dipende comunque dal singolo programma stesso. Da "rminfo"

'-f' '--force' Ignora i file inesistenti e gli operandi mancanti e non richiede mai all'utente. Ignora qualsiasi opzione '--interactive' ('-i') precedente.

'-i' Richiedi se rimuovere ciascun file. Se la risposta non è affermativa, il file viene ignorato. Ignora qualsiasi opzione '--force' ('-f') precedente. Equivalente a '--interactive = always'.

Come suggerimento generale: di infosolito è più dettagliato di man, che di solito è più dettagliato --helpdell'opzione.

Non esiste una "precedenza" per i flag, ogni programma li gestisce come desidera. La maggior parte fa un certo sforzo per raccogliere tutte le bandiere e verificare la presenza di conflitti, per strumenti standard (come i riferimenti rm(1)) gli standard pertinenti potrebbero imporre qualcosa (ma, di nuovo, la tua versione particolare potrebbe essere sciatta nell'interpretare i casi angolari dello standard / non essere specificamente testata per loro).

Per il programmatore che scrive il programma, è più semplice considerare gli argomenti (flag e altri) in rigoroso ordine da sinistra a destra, e forse salvare quando si colpisce un po 'di intoppo. Se si utilizza una libreria per gestire i flag (come getopt(3), ci sono diverse versioni fluttuanti), il programmatore presumibilmente fa ciò che risulta più facile / naturale. I programmatori sono persone, le persone sono pigre (o almeno non amano pensare all'esplosione combinatoria).