explanation for exec functions

[techgroups.bk]

i know the exec family functions usage. but it is like same as
system function.
but kernel uses exec function to startup the c program.
so can anyone tell the exact usage of the exec function usage.

 

[Ian Collins]

i know the exec family functions usage. but it is like same as
system function.
but kernel uses exec function to startup the c program.
so can anyone tell the exact usage of the exec function usage.

Try comp.unix.programmer.

 

[Martin Ambuhl]

i know the exec family functions usage. but it is like same as
system function.
but kernel uses exec function to startup the c program.
so can anyone tell the exact usage of the exec function usage.

Any function in the exec*() family will be declared in a header which is
not among the standard C headers. The usual suspect is <unistd.h>,
including execl, execle, execlp, execlpe, execv, execve, execvp, execve,
and execvpe. In a system that claims to be POSIX-compliant, they are
governed, the last I checked, by POSIX 1003.2-1992 and 1003.1-2001, not
by anything to do with the C language. This means they are specific to
(a group of) implementations, not portable, and not part of C. Anyone
who calls himself "techgroups" should know how to read his documentation
and how to post to newsgroups concerned with UNIX (as suggested by
<unistd.h>) and POSIX rather than to a language newsgroup for which such
functions are obviously not topical.

If you are not running on a UNIX-like implementation or without a
claimed POSIX-compliant environment, you may be running on one, as in
MSDOS and WINDOWS have frequently been the case, that uses the
<process.h> header. Such systems conform to absolutely no standard at
all. Often in such systems the exec* family is just a synonym for the
spawn* family with the spawn* mode parameter set to P_OVERLAY. Again,
you ought know how to read your documentation and how to post to a
relevant (probably MSDOS, WINDOWS, 4DOS, or NDOS) newsgroup instead of
to this unrelated one.

Now, there are C textbooks that, despite what I have written above, deal
with these functions. That is because in early, pre-standardization
days most C users were also UNIX users and there was a good deal of
confusion about what was an implemtation or system function and what was
a C library function. Harbison & Steele's _C: A Reference Manual_ was
first published in 1985, four years before the first standard was
adopted. They have retained sections dealing with non-standard
"traditional" functions like this. Their explanation in the 5th edition
of the exec* family is probably as much as you could need, and is found
in section 16.7.1 (pp. 416-7).

 

[CBFalconer]

i know the exec family functions usage. but it is like same as
system function. but kernel uses exec function to startup the c
program. so can anyone tell the exact usage of the exec function
usage.

There is no exec function in standard C. Thus answers to this are
off-topic on c.l.c. Try comp.unix.programmer.

 

[Antoninus Twink]

i know the exec family functions usage. but it is like same as system
function. but kernel uses exec function to startup the c program. so
can anyone tell the exact usage of the exec function usage.

It's not clear exactly what your question is - I assume you can access
the exec manpage just as well as the rest of us to find out how to use
it.

Guess: you'd like to know why one might use fork()/exec() instead of
system().

There are several reasons. Basically, system() is a convenient wrapper
for fork/exec - it forks a shell, which in turn forks whatever program
you specify in the argument you give to system(). Really, saving a
couple lines of code is all system() has going for it, plus built-in
shell globbing for your arguments if that happens to be useful.

The main thing that makes system() problematic is that shell invocation.
Firstly, this is obviously an extra overhead that you can avoid by using
fork/exec directly yourself. Then there are security issues: some
implementations of system() call the shell specified in the SHELL
environment variable, rather than /bin/sh, which means you should avoid
system() in setuid programs. Then there are the usual considerations
that you need to make sure malicious users can't control the string that
gets passed to system() to get the shell interpreter to do bad things.

Finally, another difference is that system() will halt the calling
thread and block some signals until the child completes, so if you want
to run a program asynchronously then fork/exec is the right choice.

 

[Richard]

There is no exec function in standard C. Thus answers to this are
off-topic on c.l.c. Try comp.unix.programmer.

Sure there is. I have a very standard C setup on my machine:

,----
| EXEC(3) -- 2008-08-20 -- GNU -- Linux Programmer's Manual
|
| NAME
| execl, execlp, execle, execv, execvp - execute a file
|
| SYNOPSIS
| #include <unistd.h>
|
`----

 

[Ian Collins]

There is no exec function in standard C. Thus answers to this are
off-topic on c.l.c. Try comp.unix.programmer.

Only 13 hours late to this party, not bad.

 

[Guest]

It's not clear exactly what your question is - I assume you can access
the exec manpage just as well as the rest of us to find out how to use
it.

Guess: you'd like to know why one might use fork()/exec() instead of
system().

There are several reasons. Basically, system() is a convenient wrapper
for fork/exec - it forks a shell, which in turn forks whatever program
you specify in the argument you give to system(). Really, saving a
couple lines of code is all system() has going for it, plus built-in
shell globbing for your arguments if that happens to be useful.

The main thing that makes system() problematic is that shell invocation.
Firstly, this is obviously an extra overhead that you can avoid by using
fork/exec directly yourself. Then there are security issues: some
implementations of system() call the shell specified in the SHELL
environment variable, rather than /bin/sh, which means you should avoid
system() in setuid programs. Then there are the usual considerations
that you need to make sure malicious users can't control the string that
gets passed to system() to get the shell interpreter to do bad things.

Finally, another difference is that system() will halt the calling
thread and block some signals until the child completes, so if you want
to run a program asynchronously then fork/exec is the right choice.

isn't it hard to get at the return value of the system()ed program
on many implementaions (ie. Unix)?

 

[Richard Bos]

isn't it hard to get at the return value of the system()ed program
on many implementaions (ie. Unix)?

AFAIK, it's not hard at all on _any_ Unix systems, but it can be hard
under many M$ OSes.

Richard

 

[Nate Eldredge]

isn't it hard to get at the return value of the system()ed program
on many implementaions (ie. Unix)?

On Unix, only very slightly. The return value of the system() function
is not exactly the number returned by the child program (as an argument
to exit(), or returned by main()). The value returned by system() is an
"exit status" which encodes this value together with some other status
information (mainly whether the child program was killed by a signal),
and it needs to be unpacked using the macros from <sys/wait.h>.

There is a little more effort needed if you *don't* use system(); after
doing fork() and exec(), you have to retrieve the exit status using
waitpid() or one of its kin. (In fact, this is needed not only to
retrieve the exit status, but also to finally clean up the child process
and prevent it from remaining a zombie.)

 

[Dik T. Winter]

> Finally, another difference is that system() will halt the calling
> thread and block some signals until the child completes, so if you want
> to run a program asynchronously then fork/exec is the right choice.

A further difference is that with fork/exec you have the ability (on
Unixy systems) to pipe input to the other program and/or pipe output
from it.

 

[Guest]

(e-mail address removed) wrote:

AFAIK, it's not hard at all on _any_ Unix systems, but it can be hard
under many M$ OSes.

strange. I don't know where I got that piece of misinformation
from. It's certainly easy enough on Linux. Has it been so for
all unixen? (I, know a rather large universe). I don't remeber
ever using system() on Windows (except for, maybe, trivial programs).
Where I might have cared is HP Unix is it possible HP Unix was
rather strange in that area?

 

[Nate Eldredge]

strange. I don't know where I got that piece of misinformation
from. It's certainly easy enough on Linux. Has it been so for
all unixen? (I, know a rather large universe). I don't remeber
ever using system() on Windows (except for, maybe, trivial programs).
Where I might have cared is HP Unix is it possible HP Unix was
rather strange in that area?

Looking at some old sources, both V7 and 3BSD had the same behavior as
modern systems, so I doubt it would have changed. HP has the man pages
online for HP-UX as far back as 10.x (circa 1995-1997) and they describe
the modern behavior as well.

 

[CBFalconer]

strange. I don't know where I got that piece of misinformation
from. It's certainly easy enough on Linux. Has it been so for
all unixen? (I, know a rather large universe). I don't remeber
ever using system() on Windows (except for, maybe, trivial
programs). Where I might have cared is HP Unix is it possible
HP Unix was rather strange in that area?

Here is the description straight from the standard. Note the
implementation defined return value.

7.20.4.6 The system function
Synopsis
[#1]
#include <stdlib.h>
int system(const char *string);

Description

[#2] If string is a null pointer, the system function
determines whether the host environment has a command
processor. If string is not a null pointer, the system
function passes the string pointed to by string to that
command processor to be executed in a manner which the
implementation shall document; this might then cause the
program calling system to behave in a non-conforming manner
or to terminate.

Returns

[#3] If the argument is a null pointer, the system function
returns nonzero only if a command processor is available.
If the argument is not a null pointer, and the system
function does return, it returns an implementation-defined
value.

 

[Keith Thompson]

Here is the description straight from the standard. Note the
implementation defined return value.

7.20.4.6 The system function

[snip]

How does that address the question? We know that the result returned
by system() is implementation-defined. The question is whether some
systems make it difficult to retrieve the result returned by the
invoked program (the value returned by main() or passed to exit()).
If your point is that the question is off-topic, just say so.