Perché argv include il nome del programma?

I programmi Unix / Linux tipici accettano gli input della riga di comando come argomento count ( int argc) e argomento vector ( char *argv[]). Il primo elemento di argvè il nome del programma, seguito dagli argomenti reali.

Perché il nome del programma viene passato all'eseguibile come argomento? Ci sono esempi di programmi che usano il proprio nome (forse una specie di execsituazione)?

Per cominciare, nota che argv[0]non è necessariamente il nome del programma. E 'ciò che il chiamante mette in argv[0]della execvechiamata di sistema (ad esempio, vedere questa domanda su Stack Overflow ). (Tutte le altre varianti di execnon sono chiamate di sistema ma interfacce per execve.)

Supponiamo, ad esempio, quanto segue (usando execl):

execl("/var/tmp/mybackdoor", "top", NULL);

/var/tmp/mybackdoorè ciò che viene eseguito ma argv[0]è impostato su top, e questo è ciò psche (o reale) topverrebbe visualizzato. Vedi questa risposta su U&L SE per ulteriori informazioni al riguardo.

Mettendo da parte tutto ciò: prima dell'avvento di fantasiosi filesystem /proc, argv[0]era l'unico modo per un processo di conoscere il proprio nome. Per cosa sarebbe utile?

• Diversi programmi personalizzano il loro comportamento in base al nome con cui sono stati chiamati (di solito tramite collegamenti simbolici o fissi, ad esempio le utility di BusyBox ; numerosi altri esempi sono forniti in altre risposte a questa domanda).
• Inoltre, servizi, demoni e altri programmi che accedono a syslog spesso antepongono il loro nome alle voci del registro; senza questo, il monitoraggio degli eventi diventerebbe quasi impossibile.

Plenty:

• Bash viene eseguito in modalità POSIX quando lo argv[0]è sh. Funziona come una shell di login quando argv[0]inizia con -.
• Vim in modo diverso quando eseguito come vi, view, evim, eview, ex, vimdiff, etc.
• Busybox, come già accennato.
• Nei sistemi con systemd come init, shutdown, reboot, ecc sono collegamenti simbolici asystemctl .
• e così via.

Storicamente, argvè solo una serie di puntatori alle "parole" della riga di comando, quindi ha senso iniziare con la prima "parola", che sembra essere il nome del programma.

E ci sono alcuni programmi che si comportano in modo diverso a seconda del nome utilizzato per chiamarli, quindi puoi semplicemente creare collegamenti diversi a loro e ottenere diversi "comandi". L'esempio più estremo che mi viene in mente è busybox , che si comporta come una dozzina di "comandi" diversi a seconda di come viene chiamato .

Modifica : riferimenti per Unix 1a edizione, come richiesto

Si può vedere ad esempio dalla funzione principale di ccquello argce argvsono già stati utilizzati. La shell copia gli argomenti parbufall'interno della newargparte del ciclo, trattando il comando stesso allo stesso modo degli argomenti. (Naturalmente, in seguito esegue solo il primo argomento, che è il nome del comando). Sembra che i execvparenti non esistessero allora.

Casi d'uso:

È possibile utilizzare il nome del programma per modificare il comportamento del programma .

Ad esempio, è possibile creare alcuni collegamenti simbolici al binario effettivo.

Un esempio famoso in cui viene utilizzata questa tecnica è il progetto busybox che installa solo un singolo binario e molti collegamenti simbolici. (ls, cp, mv, ecc.). Lo stanno facendo per risparmiare spazio di archiviazione perché i loro target sono piccoli dispositivi integrati.

Questo è usato anche setarchda util-linux:

$ ls -l /usr/bin/ | grep setarch
lrwxrwxrwx 1 root root           7 2015-11-05 02:15 i386 -> setarch
lrwxrwxrwx 1 root root           7 2015-11-05 02:15 linux32 -> setarch
lrwxrwxrwx 1 root root           7 2015-11-05 02:15 linux64 -> setarch
-rwxr-xr-x 1 root root       14680 2015-10-22 16:54 setarch
lrwxrwxrwx 1 root root           7 2015-11-05 02:15 x86_64 -> setarch

Qui stanno usando questa tecnica sostanzialmente per evitare molti file sorgente duplicati o semplicemente per mantenere le fonti più leggibili.

Un altro caso d'uso sarebbe un programma che deve caricare alcuni moduli o dati in fase di esecuzione. Avere il percorso del programma consente di caricare i moduli da un percorso relativo alla posizione del programma .

Inoltre, molti programmi stampano messaggi di errore, incluso il nome del programma .

Perché :

1. Perché è la convenzione POSIX ( man 3p execve):

argv è una matrice di stringhe di argomenti passate al nuovo programma. Per convenzione, la prima di queste stringhe dovrebbe contenere il nome file associato al file in esecuzione.

2. È standard C (almeno C99 e C11):

Se il valore di argc è maggiore di zero, la stringa indicata da argv [0] rappresenta il nome del programma; argv [0] [0] deve essere il carattere null se il nome del programma non è disponibile dall'ambiente host.

Si noti che lo standard C dice "nome del programma" non "nome file".

Oltre ai programmi che modificano il loro comportamento in base al modo in cui sono stati chiamati, trovo argv[0]utile nella stampa l'utilizzo di un programma, in questo modo:

printf("Usage: %s [arguments]\n", argv[0]);

Ciò fa sì che il messaggio di utilizzo utilizzi sempre il nome con cui è stato chiamato. Se il programma viene rinominato, il suo messaggio di utilizzo cambia con esso. Include anche il nome del percorso con cui è stato chiamato:

# cat foo.c 
#include <stdio.h>
int main(int argc, char **argv) { printf("Usage: %s [arguments]\n", argv[0]); }
# gcc -Wall -o foo foo.c
# mv foo /usr/bin 
# cd /usr/bin 
# ln -s foo bar
# foo
Usage: foo [arguments]
# bar
Usage: bar [arguments]
# ./foo
Usage: ./foo [arguments]
# /usr/bin/foo
Usage: /usr/bin/foo [arguments]

È un bel tocco, specialmente per piccoli strumenti / script speciali che potrebbero vivere ovunque.

Questa sembra una pratica comune anche negli strumenti GNU, vedi lsad esempio:

% ls --qq
ls: unrecognized option '--qq'
Try 'ls --help' for more information.
% /bin/ls --qq
/bin/ls: unrecognized option '--qq'
Try '/bin/ls --help' for more information.

Uno esegue la tipizzazione del programma: program_name0 arg1 arg2 arg3 ....

Quindi la shell dovrebbe già dividere il token e il primo token è già il nome del programma. E BTW quindi ci sono gli stessi indici sul lato del programma e sulla shell.

Penso che questo sia stato solo un trucco pratico (all'inizio) e, come vedi in altre risposte, è stato anche molto utile, quindi questa tradizione è stata continuata e impostata come API.

Fondamentalmente, argv include il nome del programma in modo da poter scrivere messaggi di errore simili prgm: file: No such file or directory, che verrebbero implementati con qualcosa del genere:

    fprintf( stderr, "%s: %s: No such file or directory\n", argv[0], argv[1] );

Un altro esempio di un'applicazione di questo è questo programma, che si sostituisce con ... se stesso, finché non si digita qualcosa che non lo è y.

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main (int argc, char** argv) {

  (void) argc;

  printf("arg: %s\n", argv[1]);
  int count = atoi(argv[1]);

  if ( getchar() == 'y' ) {

    ++count;

    char buf[20];
    sprintf(buf, "%d", count);

    char* newargv[3];
    newargv[0] = argv[0];
    newargv[1] = buf;
    newargv[2] = NULL;

    execve(argv[0], newargv, NULL);
  }

  return count;
}

Ovviamente, un certo esempio inventato, seppur interessante, ma penso che questo possa avere degli usi reali - per esempio, un binario auto-aggiornante, che riscrive il proprio spazio di memoria con una nuova versione di se stesso che ha scaricato o modificato.

Esempio:

$ ./res 1
arg: 1
y
arg: 2
y
arg: 3
y
arg: 4
y
arg: 5
y
arg: 6
y
arg: 7
n

7 | $

Fonte e alcune altre informazioni .

Il percorso del programma è argv[0], in modo che il programma possa recuperare i file di configurazione ecc. Dalla sua directory di installazione.
Ciò sarebbe impossibile senza argv[0].

ccache si comporta in questo modo per imitare diverse chiamate ai binari del compilatore. ccache è una cache di compilazione - l'intero punto non è mai quello di compilare lo stesso codice sorgente due volte, ma invece restituire il codice oggetto dalla cache, se possibile.

Dalla pagina man di ccache , "ci sono due modi per usare ccache. Puoi prefissare i tuoi comandi di compilazione con ccache oppure puoi lasciare che ccache si maschera come compilatore creando un link simbolico (chiamato come compilatore) a ccache. Il primo metodo è molto utile se si desidera semplicemente provare ccache o si desidera utilizzarlo per alcuni progetti specifici. Il secondo metodo è più utile quando si desidera utilizzare ccache per tutte le compilation. "

Il metodo symlink prevede l'esecuzione di questi comandi:

cp ccache /usr/local/bin/
ln -s ccache /usr/local/bin/gcc
ln -s ccache /usr/local/bin/g++
ln -s ccache /usr/local/bin/cc
ln -s ccache /usr/local/bin/c++
... etc ...

... il cui effetto è consentire a ccache di catturare qualsiasi comando che altrimenti sarebbe andato ai compilatori, permettendo così a ccache di restituire un file memorizzato nella cache o passare il comando al compilatore effettivo.