First argument lost when doing exec

[Goh, Yong Kwang]

I'm currently using execvp() for my lab program and I realise that the
first argument (args[0]) I pass to execvp is always not passed to the
file ("/bin/ls") being executed.

I'm using gcc compiler (3.3.1) running under Cygwin from Redhat.

I've done a test program which looks like this:

main(){
char* args[3];

args[0] = "--color=auto";
args[1] = "-l";
args[2] = NULL;

execvp("/bin/ls", args);
}

The purpose of the --color=auto switch is to enable a color listing of
the files and directories. As it turns out, the output is the same as
/bin/ls -l. Minus the --color=auto.

main(){
char* args[4];

args[0] = "-dummy";
args[1] = "--color=auto";
args[2] = "-l";
args[3] = NULL;

execvp("/bin/ls", args);
}

If I add in a dummy for the first argument (-dummy at args[0]) then
the output is equivalent to /bin/ls --color=auto -l. Minus the -dummy.
We can see that args[0] is always not passed to /bin/ls.

Is this a bug or is my understanding of exec* parameters wrong? Why is
this happening?

 

[Richard Heathfield]

Goh, Yong Kwang wrote:

Is this a bug or is my understanding of exec* parameters wrong?

Your understanding of exec* parameters is wrong. Since the exec* functions
are not part of ISO C, however, they're not topical here in the comp.lang.c
newsgroup. Ask in comp.unix.programmer and you'll get a superb answer, I'm
sure.

 

[Derk Gwen]

(e-mail address removed) (Goh, Yong Kwang) wrote:
# I'm currently using execvp() for my lab program and I realise that the
# first argument (args[0]) I pass to execvp is always not passed to the
# file ("/bin/ls") being executed.
#
# I'm using gcc compiler (3.3.1) running under Cygwin from Redhat.
#
# I've done a test program which looks like this:
#
# main(){
# char* args[3];
#
# args[0] = "--color=auto";
# args[1] = "-l";
# args[2] = NULL;
#
# execvp("/bin/ls", args);
# }

The args passed in are the argc/argv passed to executed program without
modification. By convention, the args[0] -> argv[0] is the name of the
executable, but that is not required. The path or open file number or other
identifier of the executable file is passed separately from the argv,
and it can be a completely different executable than the one indicated
in the argv.

# args[0] = "-dummy";

To follow the conventions programs expect, it is your responsibility to do
args[0] = "ls"
or
args[0] = "/bin/ls";

 

[Gordon Burditt]

I'm currently using execvp() for my lab program and I realise that the

first argument (args[0]) I pass to execvp is always not passed to the
file ("/bin/ls") being executed.

Hint: what is the value of argv[0] used for by a C program
when it is run? Does this suggest a reason why args[0] is
apparently ignored by /bin/ls?

Gordon L. Burditt

 

[Ben Peddell]

I'm currently using execvp() for my lab program and I realise that the
first argument (args[0]) I pass to execvp is always not passed to the
file ("/bin/ls") being executed.

I'm using gcc compiler (3.3.1) running under Cygwin from Redhat.

I've done a test program which looks like this:

main(){
char* args[3];

args[0] = "--color=auto";
args[1] = "-l";
args[2] = NULL;

execvp("/bin/ls", args);
}

This is equivalent to calling ls via a symbolic link named `--color=auto'.

The purpose of the --color=auto switch is to enable a color listing of
the files and directories. As it turns out, the output is the same as
/bin/ls -l. Minus the --color=auto.

main(){
char* args[4];

args[0] = "-dummy";
args[1] = "--color=auto";
args[2] = "-l";
args[3] = NULL;

execvp("/bin/ls", args);
}

Now you're calling ls a `-dummy'

If I add in a dummy for the first argument (-dummy at args[0]) then
the output is equivalent to /bin/ls --color=auto -l. Minus the -dummy.
We can see that args[0] is always not passed to /bin/ls.

Is this a bug or is my understanding of exec* parameters wrong? Why is
this happening?

args[0] is the name that the program calls another program.
Let's take "grep" as an example.
If args[0] is "grep", then /bin/grep will act as the standard grep.
If args[0] is "egrep", then /bin/grep will act as the extended grep.
If args[0] is "fgrep", then /bin/grep will act as the fixed-string grep.

To make my point:
The program:


#include <unistd.h>

int main (int argc, char **argv){
if (argc < 2){
return 1;
} else {
execvp (argv[0], &argv[1]);
}
return 2;
}


The testing:


$ printf "hello\nbye\nhe|by\nhe|b[y]\n" | ./execvp grep grep 'he|b[y]'
he|by
$ printf "hello\nbye\nhe|by\nhe|b[y]\n" | ./execvp grep egrep 'he|b[y]'
hello
bye
he|by
he|b[y]
$ printf "hello\nbye\nhe|by\nhe|b[y]\n" | ./execvp grep fgrep 'he|b[y]'
he|b[y]