spotvt01

I know of two approaches
1) fork, dup2, execl (you can see this approach in minicom or busybox telnet)
2) system(command)

I'm used to going through method #1 but a friend pointed out that you can do the redirection within the shell via "1>&<file descriptor>" in the command string. This moves about 30 lines of code down to aout 2-3.

Can anyone lend some insight as to why one might prefer method #1 over method #2 or vice versa? Even thoguht I first learned to do this kind of thing via method #1, I'm favoring method #1.

Thoughts?

-spot

CornedBee

There's also popen(). It really depends what you want.

fork/exec is the low-level variant. You have a lot of control over the child process this way, such as the ability to freely manipulate its file descriptors, its environment, etc.

system is not suitable if you want to communicate with the child, since it blocks until the child exits. If that's fine with you, it's the easiest way of starting a subprocess.

popen is best if you want a child process to communicate with but you don't need much control. It basically does the fork/exec thing, passing the first argument as the command line to an interpreting shell (/bin/sh on Linux), and capturing the read or write stream in a C FILE*. The biggest limitation of popen is that you cannot both input and output - the resulting FILE* is never read-write.

__________________
All the buzzt!
CornedBee

"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law

spotvt01

rather, let me say I'm favoring method #2 ... a lot less code

Thanx for responding CornedBee ....
Are we talking about a large difference in overhead b/n system / fork&exec ?

-spot

CornedBee

Well, system() forks once to start a shell, and the shell will probably fork again to execute your program.

__________________
All the buzzt!
CornedBee

"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law