georg@SunLab13.essex.ac.uk (Georgatos G) (12/01/89)
*******************************************************************************
_______________________________________________________________________________
Does anybody know how to call an executable file from
a c-program ?
I am using the Unix-CC copiler.
_______________________________________________________________________________
Hgg89.
gwyn@smoke.BRL.MIL (Doug Gwyn) (12/02/89)
In article <2615@servax0.essex.ac.uk> georg@essex.ac.uk writes: > Does anybody know how to call an executable file from > a c-program ? > I am using the Unix-CC copiler. The simplest method is to invoke the system() library function. If your program needs to provide input to, or capture output from, the command, then popen() should be used. If you need to do something more elaborate then you need to study UNIX system programming; Kernighan & Pike's "The UNIX Programming Environment" is recommended.
cpcahil@virtech.uucp (Conor P. Cahill) (12/03/89)
In article <2615@servax0.essex.ac.uk>, georg@SunLab13.essex.ac.uk (Georgatos G) writes: > Does anybody know how to call an executable file from > a c-program ? > I am using the Unix-CC copiler. Look up the word execute in the permuted index for you programmers reference manual. Therein you will find references to the exec(2) manual page. If you want to use the simplest interface (but much less efficient and much more prone to security holes) you can use the system(3) library call (which for some reason is in the index as "issue a shell command" when it should be something like "execute commands using the shell" or some such thing). All of the following will perform an "ls -l dir". If you use one of the exec()s you need to use fork() and wait() to run the program as a sub-process. char *args[10]; execl("/bin/ls","ls","-l","dir",(char *) 0); execlp("ls","ls","-l","dir",(char *) 0); args[0] = "ls", args[1] = "-l", args[2] = "dir", args[3] = NULL; execv("/bin/ls",args); execvp("ls",args); execvp(args[0],args); system("ls -l dir"); -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
steve@thelake.UUCP (Steve Yelvington) (12/04/89)
In article <1989Dec2.161237.23913@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes ... >In article <2615@servax0.essex.ac.uk>, georg@SunLab13.essex.ac.uk (Georgatos G) writes: >> Does anybody know how to call an executable file from >> a c-program ? >> I am using the Unix-CC copiler. >Look up the word execute in the permuted index for you programmers reference >manual. Therein you will find references to the exec(2) manual page. > >If you want to use the simplest interface (but much less efficient and >much more prone to security holes) you can use the system(3) library >call (which for some reason is in the index as "issue a shell command" >when it should be something like "execute commands using the shell" or >some such thing). > >All of the following will perform an "ls -l dir". If you use one of the >exec()s you need to use fork() and wait() to run the program as a sub-process. > A couple of (probably stupid) questions: 1. On the net, I often see (non-code) references to functions with numbers inside the parens, as in system(3) and exec(2). None of the documentation I have uses these numbers. What do they mean, and where do they come from? 2. Can someone explain or (*explain) the differences between the spawn, exec and fork families of process-control functions? K&R 1, Harbison & Steele, and the lesser reference works that I have are of no help on this issue. What does the new standard include? -- Steve Yelvington, up at the lake in Minnesota ... pwcs.StPaul.GOV!stag!thelake!steve (UUCP)
fredex@cg-atla.UUCP (Fred Smith) (12/05/89)
In article <2615@servax0.essex.ac.uk> georg@essex.ac.uk writes: > > > >******************************************************************************* >_______________________________________________________________________________ > Does anybody know how to call an executable file from > a c-program ? > I am using the Unix-CC copiler. >_______________________________________________________________________________ > Hgg89. > > If you want to execute a program named "SubProgram" from within an already running program, an easy way to do it is to use a statement like this: system ("SubProgram"); This assumes that SubProgram is located in a place that is on your path. There are other ways, too, but this one is probably easiest. Fred
cpcahil@virtech.uucp (Conor P. Cahill) (12/05/89)
In article <1103891355263101@thelake.UUCP>, steve@thelake.UUCP (Steve Yelvington) writes: > 1. On the net, I often see (non-code) references to functions with numbers > inside the parens, as in system(3) and exec(2). None of the > documentation I have uses these numbers. What do they mean, and where > do they come from? These are manual section pages from most UNIX manual sets. 1 - programs 1m - SYSV: system administration programs 2 - system calls. 3* - library functions 4 - BSD: special files SYSV: file formats 5 - BSD: file formats SYSV: miscellany 6 - games 7 - SYSV: special files 8 - BSD: system administration programs -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
steve@thelake.UUCP (Steve Yelvington) (12/07/89)
I received many interesting responses to the followup in which I raised a couple of questions. (Thanks to all who responded.) Here is a summary, with apologies if I've mangled anybody's explanations: In article <1103891355263101@thelake.UUCP> I wrote: >1. On the net, I often see (non-code) references to functions with numbers > inside the parens, as in system(3) and exec(2). These numbers refer to sections of the Un*x manual. For non-Un*x programmers, their primary utility is to serve as a warning that the writer may be making Un*x assumptions as opposed to MS-DOS or whatever assumptions. :-) >2. Can someone explain or (*explain) the differences between the spawn, > exec and fork families of process-control functions? K&R 1, Harbison > & Steele, and the lesser reference works that I have are of no help > on this issue. What does the new standard include? The most important thing I learned is this: If you are interested in C portability, the whole area of process control is a minefield. It is heavily dependent on the capabilities of the operating system. The draft ANSI C standard doesn't provide either spawn or fork/exec. POSIX addresses the issue, but as Peter da Silva notes (in another msg thread), > POSIX is a standard for the UNIX OS interface. It is not implementable > on most personal computers, for example. There is a huge gap between > what ANSI specifies and what's useful on most systems, and another > huge gap between that and POSIX. Fork/exec/wait is the standard way of calling another program under Unix: fork() makes an exact duplicate of a running process, running concurrently; exec() (called by the child) overlays the (child) process with another program that slips comfortably into its process slot; and wait() (called by the parent) suspends the parent process until the child exits. Since MS-DOS doesn't have a fork() system call, most MS-DOS implementations supply the spawn() family of functions to call another process and wait for it to terminate without overlaying the current process. Some also provide exec(), which wipes out the parent -- there is no return, and wait() with such an implementation won't work. Some libraries for single-tasking systems (Mark Williams C on the Atari ST, for instance) provide neither fork nor spawn families. Others (such as dLibs) attempt to provide as much fork/exec/wait functionality as is possible in the host environment, but don't use the spawn() method employed by the MS-DOS compilers. The system() call is most likely to be portable, although it too is not without potential trouble. H&S (p.364) notes that it passes its argument to a command processor for execution in an implementation-defined way. On most systems, this will load a new command processor (which takes time and memory). Others may allow the argument to be passed backward to an original or parent shell. In ANSI C, system((char*) NULL) should return 0 if there is no command processor present -- as might be the case with, for example, GEM or the Macintosh environments. I have three C compilers for my machine; running system("Hello") will work dependably (if the hello program is present) on two of them and fail on the third unless its proprietary shell is present. Conclusion: Expect headaches when porting any program that wants to execute other processes. -- Steve Yelvington at the (almost frozen enough to skate) lake in Minnesota UUCP: ... pwcs.StPaul.GOV!stag!thelake!steve