Is it possible for a program to get number of spaces between command line arguments in POSIX?

Question

Say if I wrote a program with the following line:

int main(int argc, char** argv)

Now it knows what command line arguments are passed to it by checking the content of argv.

Can the program detect how many spaces between arguments? Like when I type these in bash:

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

Environment is a modern Linux (like Ubuntu 16.04), but I suppose the answer should apply to any POSIX-compliant systems.

Answer 1

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.

Answer 2

It's not meaningful to talk of "spaces between arguments"; that's a shell concept.

A shell's job is to take whole lines of input and form them into arrays of arguments to start commands with. This may involve parsing quoted strings, expanding variables, file wildcards and tilde expressions, and more. The command is started with a standard exec system call, which accepts a vector of strings.

Other ways exist to create a vector of strings. Many programs fork and exec their own sub-processes with predetermined command invocations - in which case, there's never such a thing as a "command line". Similarly, a graphical (desktop) shell might start a process when a user drags a file icon and drops it on a command widget - again, there's no textual line to have characters "between" arguments.

As far as the invoked command is concerned, what goes on in a shell or other parent/precursor process is private and hidden - we only see the array of strings that standard C specifies that main() can accept.

Answer 3

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.

Answer 4

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.

Answer 5

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 '%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')

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.

Answer 6

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)