Di 'se ho scritto un programma con la seguente riga:

int main(int argc, char** argv)

Ora sa quali argomenti della riga di comando gli vengono passati controllando il contenuto di argv.

Il programma può rilevare quanti spazi tra gli argomenti? Come quando li scrivo in bash:

ibug@linux:~ $ ./myprog aaa bbb
ibug@linux:~ $ ./myprog       aaa      bbb

L'ambiente è un moderno Linux (come Ubuntu 16.04), ma suppongo che la risposta dovrebbe applicarsi a tutti i sistemi compatibili con POSIX.

Non è significativo parlare di "spazi tra argomenti"; questo è un concetto di shell.

Il lavoro di una shell è prendere intere righe di input e formarle in matrici di argomenti con cui avviare i comandi. Ciò può comportare l'analisi di stringhe tra virgolette, l'espansione di variabili, i caratteri jolly dei file e le espressioni tilde e altro ancora. Il comando viene avviato con una execchiamata di sistema standard , che accetta un vettore di stringhe.

Esistono altri modi per creare un vettore di stringhe. Molti programmi eseguono fork ed eseguono i propri processi secondari con invocazioni di comandi predeterminate, nel qual caso non esiste mai una "riga di comando". Allo stesso modo, una shell grafica (desktop) potrebbe avviare un processo quando un utente trascina un'icona di file e la rilascia su un widget di comando - di nuovo, non c'è una riga testuale per avere caratteri "tra" argomenti.

Per quanto riguarda il comando invocato, ciò che accade in una shell o in un altro processo genitore / precursore è privato e nascosto - vediamo solo l'array di stringhe che lo standard C specifica che main() può accettare.

In generale, no. L'analisi della riga di comando viene eseguita dalla shell che non rende la riga non analizzata disponibile per il programma chiamato. In effetti, il tuo programma potrebbe essere eseguito da un altro programma che ha creato l'argv non analizzando una stringa ma costruendo un array di argomenti a livello di programmazione.

No, questo non è possibile, a meno che gli spazi non facciano parte di un argomento.

Il comando accede ai singoli argomenti da un array (in una forma o nell'altra a seconda del linguaggio di programmazione) e la riga di comando effettiva può essere salvata in un file di cronologia (se digitata a un prompt interattivo in una shell che ha file di cronologia), ma è mai passato al comando in nessuna forma.

Tutti i comandi su Unix sono infine eseguiti da una delle exec()famiglie di funzioni. Questi prendono il nome del comando e un elenco o una matrice di argomenti. Nessuno di loro accetta una riga di comando come digitata al prompt della shell. La system()funzione lo fa, ma il suo argomento stringa viene successivamente eseguito da execve(), che, di nuovo, accetta una matrice di argomenti anziché una stringa della riga di comando.

In generale, non è possibile, come spiegato in molte altre risposte.

Tuttavia, le shell Unix sono programmi ordinari (e stanno interpretando la riga di comando e la stanno traballando , cioè espandendo il comando prima di farlo forke execveper esso). Vedi questa spiegazione sulle bashoperazioni della shell . Potresti scrivere la tua shell (o puoi applicare patch a una shell software esistente , ad esempio GNU bash ) e usarla come shell (o anche come shell di accesso, vedi passwd (5) e shells (5) ).

Ad esempio, è possibile che il proprio programma shell inserisca l'intera riga di comando in alcune variabili di ambiente ( MY_COMMAND_LINEad esempio, immaginiamo ) oppure utilizzare qualsiasi altro tipo di comunicazione tra processi per trasmettere la riga di comando dalla shell al processo figlio-.

Non capisco perché vorresti farlo, ma potresti codificare una shell che si comporta in questo modo (ma consiglio di non farlo).

A proposito, un programma potrebbe essere avviato da un programma che non è una shell (ma che fa fork (2) quindi esegue (2) , o semplicemente unexecve per avviare un programma nel suo processo corrente). In tal caso non esiste alcuna riga di comando e il programma potrebbe essere avviato senza un comando ...

Nota che potresti avere un sistema Linux (specializzato) senza alcuna shell installata. Questo è strano e insolito, ma possibile. Dovrai quindi scrivere un programma init specializzato avviando altri programmi secondo necessità, senza usare alcuna shell ma facendo forke execvechiamate di sistema.

Leggi anche Sistemi operativi: tre semplici passaggi e non dimenticare che execveè praticamente sempre una chiamata di sistema (su Linux, sono elencati in syscalls (2) , vedi anche intro (2) ) che reinizializzano lo spazio di indirizzi virtuale (e alcuni altri cose) del processo che lo sta facendo.

Puoi sempre dire alla tua shell di dire alle applicazioni quale codice della shell porta alla loro esecuzione. Ad esempio, con zsh, passando quelle informazioni nella $SHELL_CODEvariabile d'ambiente usando l' preexec()hook ( printenvusato come esempio, useresti getenv("SHELL_CODE")nel tuo programma):

$ preexec() export SHELL_CODE=$1
$ printenv SHELL_CODE
printenv SHELL_CODE
$ printenv  SHELL_CODE
printenv  CODE
$ $(echo printenv SHELL_CODE)
$(echo printenv SHELL_CODE)
$ for i in SHELL_CODE; do printenv "$i"; done
for i in SHELL_CODE; do printenv "$i"; done
$ printenv SHELL_CODE; : other command
printenv SHELL_CODE; : other command
$ f() printenv SHELL_CODE
$ f
f

Tutti quelli sarebbero eseguiti printenvcome:

execve("/usr/bin/printenv", ["printenv", "SHELL_CODE"], 
       ["PATH=...", ..., "SHELL_CODE=..."]);

Permettere printenvdi recuperare il codice zsh che porta all'esecuzione di printenvcon quegli argomenti. Quello che vorresti fare con queste informazioni non mi è chiaro.

Con bash, la caratteristica più vicina a quella che zshuserebbe preexec()sarebbe la sua $BASH_COMMANDin una DEBUGtrappola, ma nota che bashfa un certo livello di riscrittura in quello (e in particolare i refactor alcuni degli spazi bianchi usati come delimitatore) e che viene applicato a ogni (bene, alcuni) comando eseguire, non l'intera riga di comando immessa al prompt (vedere anche l' functraceopzione).

$ trap 'export SHELL_CODE="$BASH_COMMAND"' DEBUG
$ printenv SHELL_CODE
printenv SHELL_CODE
$ printenv $(echo 'SHELL_CODE')
printenv $(echo 'SHELL_CODE')
$ for i in SHELL_CODE; do printenv "$i"; done; : other command
printenv "$i"
$ printf '%s\n' "$(printenv "SHELL_CODE")"
printf '%s\n' "$(printenv "SHELL_CODE")"
$ set -o functrace
$ printf '%s\n' "$(printenv "SHELL_CODE")"
printenv "SHELL_CODE"
$ print${-+env  }    $(echo     'SHELL_CODE')
print${-+env  } $(echo     'SHELL_CODE')

Guarda come alcuni degli spazi che sono delimitatori nella sintassi del linguaggio shell sono stati compressi in 1 e come non sempre la riga di comando completa non viene sempre passata al comando. Quindi probabilmente non è utile nel tuo caso.

Nota che non consiglierei di fare questo tipo di cose, poiché potenzialmente stai perdendo informazioni sensibili ad ogni comando come in:

echo very_secret | wc -c | untrustedcmd

perderebbe quel segreto a entrambi wce untrustedcmd.

Certo, potresti fare quel genere di cose per altre lingue oltre alla shell. Ad esempio, in C, è possibile utilizzare alcune macro che esportano il codice C che esegue un comando nell'ambiente:

#include <unistd.h>
#include <stdlib.h>
#include <sys/wait.h>
#define WRAP(x) (setenv("C_CODE", #x, 1), x)

int main(int argc, char *argv[])
{
  if (!fork()) WRAP(execlp("printenv", "printenv", "C_CODE", NULL));
  wait(NULL);
  if (!fork()) WRAP(0 + execlp("printenv",   "printenv", "C_CODE", NULL));
  wait(NULL);
  if (argc > 1 && !fork()) WRAP(execvp(argv[1], &argv[1]));
  wait(NULL);
  return 0;
}

Esempio:

$ ./a.out printenv C_CODE
execlp("printenv", "printenv", "C_CODE", NULL)
0 + execlp("printenv", "printenv", "C_CODE", NULL)
execvp(argv[1], &argv[1])

Guarda come alcuni spazi sono stati condensati dal pre-processore C come nel caso bash. Nella maggior parte, se non in tutte le lingue, la quantità di spazio utilizzata nei delimitatori non fa alcuna differenza, quindi non sorprende che il compilatore / interprete si prenda qualche libertà con loro qui.

Aggiungerò solo ciò che manca nelle altre risposte.

No

Vedi altre risposte

Forse, in un certo senso

Non c'è nulla che possa essere fatto nel programma, ma c'è qualcosa che può essere fatto nella shell quando si esegue il programma.

Devi usare le virgolette. Quindi invece di

./myprog      aaa      bbb

devi fare uno di questi

./myprog "     aaa      bbb"
./myprog '     aaa      bbb'

Questo passerà un singolo argomento al programma, con tutti gli spazi. C'è una differenza tra i due, il secondo è letterale, esattamente la stringa come appare (tranne che 'deve essere digitata come \'). Il primo interpreterà alcuni personaggi, ma suddiviso in diversi argomenti. Vedi quotazione della shell per maggiori informazioni. Quindi non è necessario riscrivere la shell, i progettisti della shell ci hanno già pensato. Tuttavia, poiché ora è un argomento, dovrai fare di più passando all'interno del programma.

opzione 2

Passa i dati in via stdin. Questo è il modo normale di ottenere grandi quantità di dati in un comando. per esempio

./myprog << EOF
    aaa      bbb
EOF

o

./myprog
Tell me what you want to tell me:
aaaa bbb
ctrl-d

(Il corsivo è l'output del programma)