Thread: Exec() Question?

  1. #1
    Registered User
    Join Date
    Apr 2008
    Posts
    167

    Exec() Question?

    Code:
    char* ls_args[2];
    ls_args[0] = "../..";
    ls_args[1] = 0;
    
    execve("/bin/ls", ls_args, 0);
    When executing the above code, it just does an ls on the current directory. Array element [0] is completely ignored.

    char* ls_args[3];
    ls_args[0] = "the first array value has absolutely no effect whatsoever";
    ls_args[1] = "../..";
    ls_args[2] = 0;

    execve("/bin/ls", ls_args, 0);
    This works; it actually does an ls on the directory two levels up. However, notice the contents of array element [0].

    What is going on here?

    I tried looking it up on the man pages, but I don't understand what it says. Here is an excerpt:

    http:// www.opengroup.org/onlinepubs/000095399/functions/exec.html

    execl(<shell path>, arg0, file, arg1, ..., (char *)0);

    The argument arg0 should point to a filename that is associated with the process being started by one of the exec functions.
    ... Huh? What file?

    Also, the examples on the same page always have the command listed twice, such as:

    ret = execle ("/bin/ls", "ls", "-l", (char *)0, env);
    Can anyone explain the purpose of the first array element in laymen's terms?
    Last edited by Paul22000; 04-07-2009 at 03:52 PM.

  2. #2
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,059
    Quote Originally Posted by Paul22000 View Post
    Code:
    http:// www.opengroup.org/onlinepubs/000095399/functions/exec.html
    
    execl(<shell path>, arg0, file, arg1, ..., (char *)0);
    The argument arg0 should point to a filename that is associated with the process being started by one of the exec functions.

    ... Huh? What file?
    <shell path> can be left unspecified, arg0 is the first argument to the shell, file is the basename of the executable stripped of its path and the remaining arguments are the options given to the executable on the command line, for ex.
    Code:
    $ /bin/ls -l /tmp
    /bin/ls is arg0 /* first argument to the shell (Korn, POSIX etc.) executing command ls */
    file is basename(arg0)  /* ls */
    arg1 is "-l"
    arg2 is "/tmp"
    execl("/bin/ls", "ls", "-l", "/tmp", (char*)0);
    Now you can see for yourself what each pointer in the array argv[] points to.

  3. #3
    Registered User
    Join Date
    Apr 2008
    Posts
    167
    "file is the basename stripped of its path"

    Sure but what is the purpose of it? Notice what I put in the example in my first post. It seems like it doesn't matter what you put at all.
    Last edited by Paul22000; 04-07-2009 at 08:09 PM.

  4. #4
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,059
    Quote Originally Posted by Paul22000 View Post
    "file is the basename stripped of its path"
    Semantically speaking, yes that's what it should be though nothing prevents anybody from putting something else there (sort of like what you did). Only caveat or downside is that the exec() family of functions does not enforce the fact that "file is the basename of the program".
    Quote Originally Posted by Paul22000 View Post
    Sure but what is the purpose of it? Notice what I put in the example in my first post. It seems like it doesn't matter what you put at all.
    No purpose except that it's the string that argv[0] points to within the exec()'d file; so for ex. if "oneprog" calls "someprog" as in:
    Code:
    execl("/full/path/to/someprog", "no effect whatsoever", "firstarg", "secondarg", (char*)0);  /* inside oneprog */
    When someprog is executed the arguments passed to its main() function would be:
    Code:
    argv[0] points to "no effect whatsover"
    argv[1] points to "firstarg"
    argv[2] points to "secondarg"
    Which is semantically incorrect since argv[0] is the name of the program which in this case should be "someprog" and not "no effect whatsoever" as in.
    Code:
    execl("/full/path/to/someprog", "someprog", "firstarg", "secondarg", (char*)0);
    Last edited by itCbitC; 04-07-2009 at 10:37 PM.

  5. #5
    Registered User
    Join Date
    Apr 2008
    Posts
    167
    Ohhhh, I see. So really the only time that this ever matters is if the program you call, somehow needs/uses arg0? (Or more specifically, if the program you call needs to know its own name for some reason.)

  6. #6
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,059
    Quote Originally Posted by Paul22000 View Post
    Ohhhh, I see. So really the only time that this ever matters is if the program you call, somehow needs/uses arg0? (Or more specifically, if the program you call needs to know its own name for some reason.)
    Helps in troubleshooting if name of the offending module can be easily identified especially if it's part of a complex software package, else there would be chaos if the name didn't make any sense.

  7. #7
    Registered User
    Join Date
    Apr 2008
    Posts
    167
    Quote Originally Posted by itCbitC View Post
    Helps in troubleshooting if name of the offending module can be easily identified especially if it's part of a complex software package, else there would be chaos if the name didn't make any sense.
    Gotcha. Thanks. At first I thought it had to be something specific (the program name without the path), so I was just baffled as to why it worked with anything. Makes sense now!

  8. #8
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,059
    Forgot to add that usually when an error occurs inside a module, its name is printed out followed by a colon and the error string. It's not hard to imagine what would happen if the name didn't match any of the object modules, for ex. if someprog couldn't locate and open() a file it would print out this error message.
    Code:
    no effect whatsoever: file not found
    Troubleshooting that error inside a complex software package would be a very challenging (if not impossible) task.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. how to force a function to never return...like exec() does it
    By creeping death in forum C Programming
    Replies: 7
    Last Post: 03-28-2009, 01:08 PM
  2. Debugging question
    By o_0 in forum C Programming
    Replies: 9
    Last Post: 10-10-2004, 05:51 PM
  3. Exec newbie question
    By Serrux in forum C++ Programming
    Replies: 22
    Last Post: 06-05-2004, 08:28 AM
  4. Question...
    By TechWins in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 07-28-2003, 09:47 PM
  5. Question, question!
    By oskilian in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 12-24-2001, 01:47 AM