ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
"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.
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 :
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:
file_pointer = popen("ifconfig eth0 up", "r");
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.
file_pointer = popen("echo -e \"aaaaa\"", "w");
?? Why? A simple printf will suffice:
f = popen ("ETH0=DHCP", "r");
To set environment variables, use putenv (or setenv):
perror("Unable to set ETH0");
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.
Originally posted by someone up there this would be easier as a shell script *
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
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.