/* THE CODE BELOW CAUSES A RUN TIME ERROR */
system ("ifconfig eth1 \"$ETH1\" netmask 255.255.255.0");

==================================
root:~# ./test-small-network-sh-2
aaaaa
No address associated with name
ifconfig: `--help' gives usage information.
==================================

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

/*******************************************/

int main()
{
FILE *f, *panic_file, *fopen();
FILE *file_pointer;

file_pointer = popen("ifconfig eth0 up", "r");
file_pointer = popen("echo -e \"aaaaa\"", "w");

f = popen ("ETH0=DHCP", "r");
f = popen ("ETH1=10.0.1.1", "r");
f = popen ("NETMASK=", "r");
f = popen ("BROADCAST=", "r");
f = popen ("GATEWAY=127.0.0.1", "r");

f = popen ("source /etc/yellowbox/network-config", "r");

panic_file = fopen ("/proc/sys/kernel/panic", "w");
putc ('5', panic_file);

f = popen ("ifconfig lo 127.0.0.1", "r");
f = popen ("ifconfig eth0 up", "r");

/* THE CODE BELOW CAUSES A RUN TIME ERROR */
system ("ifconfig eth1 \"$ETH1\" netmask 255.255.255.0");

pclose (f);
pclose (file_pointer);
fclose (panic_file);
}

From the man pages, "man system"

"Do not use system() from a program with suid or sgid privileges, because strange values for some environment variables might be used to subvert system integrity. Use the exec (3) family of functions instead, but not execlp (3) or execvp (3). system() will not, in fact, work properly from programs with suid or sgid privileges on systems on which /bin/sh is bash version 2, since bash 2 drops privileges on startup. (Debian uses a modified bash which does not do this when invoked as sh). The check for the availability of /bin/sh is not actually performed; it is always assumed to be available. ISO C specifies the check, but POSIX.2 specifies that the return shall always be non-zero, since a system without the shell is not conforming, and it is this that is implemented.

It is possible for the shell command to return 127, so that code is not a sure indication that the execve() call failed."

If you're using a fairly recent build chances are you're using bash 2.05 or thereabouts - /bin/sh is probably a link to bash. I don't have experience of your problem but the man page suggests that you're asking for trouble doing what you're doing.

1) Is this how exec should be used as shown below ?
2) What library needs to be included ?

=====================
#include < >

main()
{
execv ("ifconfig eth0 up", "r");
}

Again from the man pages (I have never done this stuff, just stumbled across some stuff that seemed useful in the man pages is all). From what I read in the man pages "man execv" you need to include <unistd.h>.

The man pages suggest that for execv a pointer to path of the file to be executed is the first argument ... then an array of pointers to null terminated strings for the rest of the arguments. So it's a bit trickier than would first seem anyway read the man pages.

Perhaps execl is more the type of thing you'd be interested in. For the record all experiments I did with execl resulted in error. I found strace quite useful for testing though. The syntax seems to be like this :

#include <unistd.h>

main()
{
const char* string1[] = {"/bin/touch\0"};
const char* string2[] = {"/root/stooge\0"};

int ret;
ret = execl(*string1, *string2);
return 0;
}

That will compile at least ... that, and other permutations bomb out bad though when run. Good luck and if you crack it post back. Perhaps one of the other exec's would be better ?

I don't get why you're using C to do a bunch of stuff that the shell could do much easier and safer.

There are alot of flaws and potential for problems with the code... for example, the code is popen'ing a series of shell variable set calls, which are returning streams (or erroring out, the code doesn't check for any form of errors here at all), and then going on without pclose'ing anything.. why popen shell calls? The code isn't using the returned streams in any way.. and speaking of error checking, there is none. At all. That is very bad!

Seriously.. for what you're trying to do, you'd be MUCH better off using a shell script.

If you are admanant on using C, then use C.. don't half-way use C. use C variables. Use forking properly, where you're actually dealing with and using streams.. for example:

I would recommend that you don't do this from inside the C binary. Use a shell script to run the ifconfig command and then run your C binary.

?? Why? A simple printf will suffice:
To set environment variables, use putenv (or setenv):
The bottom line is.. there is nothing going on in this code that should happen in a C program. I would highly recommend you use a shell script.

this is what i said when you first started posting about this problem

I'm assuming that you're refering to Linh, when you say "you", seeing as how this is my first post in this thread. (=

yes, sorry that is quite ambiguous

Yeah of course this would be easier as a shell script, a *lot* easier. You think he doesn't know that ? Maybe he's working to a crazy design that is rigid in specs and he has no choice. Who knows.

Remember too we only see part of the story. Maybe he's got a fancy graphical front end going in openGL for network config. What would you do, try system calls from C or try 3d graphics from shell script ?

* disclaimer - quote may or may not be an actual quote

Pres:

What you've said may be true... but I have seen no evidence to support it, nor do I believe that there is any valid reason for making system calls like this.

When I was learning perl, a guru was guiding me along, and critiqued some of my code. I was making shell calls. He said "If you're going to use perl, use perl.". Meaning, take advantage of the perl environment and use it's methods of doing things, instead of taking shortcuts and doing shell calls.

I still hold strong to that to this day.