In general, no. Command line parsing is done by the shell which does not make the unparsed line available to the called program. In fact, your program might be executed from another program which created the argv not by parsing a string but by constructing an array of arguments programmatically.

No, this is not possible, unless the spaces are part of an argument.

The command accesses the individual arguments from an array (in one form or another depending on programming language) and the actual command line may be saved to a history file (if typed at an interactive prompt in a shell that has history files), but is never passed on to the command in any form.

All commands on Unix are in the end executed by one of the exec() family of functions. These take the command name and a list or array of arguments. None of them takes a command line as typed at the shell prompt. The system() function does, but its string argument is later executed by execve(), which, again, takes an array of arguments rather than a command line string.

In general, it is not possible, like several other answers explained.

However, Unix shells are ordinary programs (and they are interpreting the command line and globbing it, i.e. expanding the command before doing fork & execve for it). See this explanation about bash shell operations. You could write your own shell (or you could patch some existing free software shell, e.g. GNU bash) and use it as your shell (or even your login shell, see passwd(5) & shells(5)).

For example, you might have your own shell program put the full command line in some environment variable (imagine MY_COMMAND_LINE for example) -or use any other kind of inter-process communication to transmit the command line from shell to child process-.

I don't understand why you would want to do that, but you might code a shell behaving in such a way (but I recommend not doing so).

BTW, a program could be started by some program which is not a shell (but which do fork(2) then execve(2), or just an execve to start a program in its current process). In that case there is no command line at all, and your program could be started without a command...

Notice that you might have some (specialized) Linux system without any shell installed. This is weird and unusual, but possible. You'll then need to write a specialized init program starting other programs as needed - without using any shell but by doing fork & execve system calls.

Read also Operating Systems : Three easy pieces and don't forget that execve is practically always a system call (on Linux, they are listed in syscalls(2), see also intro(2)) which reinitialize the virtual address space (and some other things) of the process doing it.

You can always tell your shell to tell applications what shell code lead to their execution. For instance, with zsh, by passing that information in the $SHELL_CODE environment variable using the preexec() hook (printenv used as an example, you'd use getenv("SHELL_CODE") in your program):

$ 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

All those would execute printenv as:

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

Allowing printenv to retrieve the zsh code that lead to the execution of printenv with those arguments. What you would want to do with that information is not clear to me.

With bash, the feature closest to zsh's preexec() would be using its $BASH_COMMAND in a DEBUG trap, but note that bash does some level of rewriting in that (and in particular refactors some of the whitespace used as delimiter) and that's applied to every (well, some) command run, not the whole command line as entered at the prompt (see also the functrace option).

$ 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 '%sn' "$(printenv "SHELL_CODE")"
printf '%sn' "$(printenv "SHELL_CODE")"
$ set -o functrace
$ printf '%sn' "$(printenv "SHELL_CODE")"
printenv "SHELL_CODE"
$ print$-+env $(echo 'SHELL_CODE')
print$-+env $(echo 'SHELL_CODE')

See how some of the spaces that are delimiters in the shell language syntax have been squeezed into 1 and how not the full command line is not always passed to the command. So probably not useful in your case.

Note that I would not advise doing this kind of thing, as you're potentially leaking sensitive information to every command as in:

echo very_secret | wc -c | untrustedcmd

would leak that secret to both wc and untrustedcmd.

Of course, you could do that kind of thing for other languages than the shell. For instance, in C, you could use some macros that exports the C code that executes a command to the environment:

#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;

Example:

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

See how some spaces were condensed by the C pre-processor like in the bash case. In most if not all languages, the amount of space used in delimiters makes no difference, so it's not surprising that the compiler/interpreter takes some liberty with them here.

I will just add what is missing in the other answers.

No

See other answers

Maybe, sort of

There is nothing that can be done in the program, but there is something that can be done in the shell when you run the program.

You need to use quotes. So instead of

./myprog aaa bbb

you need to do one of these

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

This will pass a single argument to the program, with all of the spaces. There is a difference between the two, the second is literal, exactly the string as it appears (except that ' must be typed as '). The first one will interpret some characters, but split into several arguments. See shell quoting for more information. So no need to rewrite the shell, the shell designers have already thought of that. However because it is now one argument, you will have to do more passing within the program.

Option 2

Pass the data in via stdin. This is the normal way to get large amounts of data into a command. e.g.

./myprog << EOF
 aaa bbb
EOF

or

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

(Italics are output of program)