How to capture the outpur of a command in c program?
Answers
Answered by
0
If you want to run shell commands from within a C program there are several options:
Do not use the shell, but bypass the shell and run the commands directly within your program. Many of the basic utilities can be accessed easily enough and system calls are available for system programming tasks. You may need to pipe( ), fork( ) andexec( ) but this is not that hard.Use system( ) to run the command if input and output are not important.Use popen( ) if control on either input or output is needed.Run the shell as a coprocess.
If you elect to bypass the shell, it can be handy to have buffered I/O. STDIO functions are available on a file descriptor with:
fdopen - associate a stream with a file descriptor
FILE *fdopen(int fd, const char *mode);
After this call, STDIO buffered I/O and standard I/O functions such as scanf( ) andprintf( ) can be used on fd.
system - run shell command
int system(const char *command);
The command is run noninteractively in a shell, output is to the terminal and your program waits for command completion. The main disadvantage with system( ) is that I/O bypasses your program unless you take steps to catch it.
popen - pipe to/from shell
FILE *popen(const char *command, const char *type);int pclose(FILE *stream);
Typically usage is: FILE *fp; char *command; /* command contains the command string (a character array) */ /* If you want to read output from command */ fp = popen(command,"r"); /* read output from command */ fscanf(fp,....); /* or other STDIO input functions */ fclose(fp); /* If you want to send input to command */ fp = popen(command,"w"); /* write to command */ fprintf(fp,....); /* or other STDIO output functions */ fclose(fp); The program cannot both send input to the command and read its output. The file fpbehaves like an ordinary STDIO file. Shell as a coprocessThe shell can be forked off as a child of the program and then commands can be both sent to it and the results can be read. More generally any other program could be run this way. There are a number of problems with this approach:First is the practical problem of keeping the processes in sync. For instance, can you recognizing when the coprocess has finished responding to a given request?Since the shell is receiving its input through a pipe and not through a terminal, it uses file not line buffering. It will not receive input until the buffer is full. Some solutions to this problem are:If you have access to the code for the coprocess you may be able to force line buffering or no buffering.Use a pseudo terminal to trick the coprocess into thinking it is connected to a terminal.Override the standard isatty( ) by dynamically linking in a version that always returns true. This will require altering the environment before calling the child coprocess, so that the child process's dynamic load library path includes the revised isatty. See isatty_preload.c for how to do this in SUN Solaris.Deadlock can occur if both processes write more than the pipe can handle. The parent may block during a big write, and so will not be able to read. This will block the child coprocess if it is also writes lots before doing a read.There are some alternatives. For example, a shell-like utility called expect can be used to programatically control a coprocess.
Do not use the shell, but bypass the shell and run the commands directly within your program. Many of the basic utilities can be accessed easily enough and system calls are available for system programming tasks. You may need to pipe( ), fork( ) andexec( ) but this is not that hard.Use system( ) to run the command if input and output are not important.Use popen( ) if control on either input or output is needed.Run the shell as a coprocess.
If you elect to bypass the shell, it can be handy to have buffered I/O. STDIO functions are available on a file descriptor with:
fdopen - associate a stream with a file descriptor
FILE *fdopen(int fd, const char *mode);
After this call, STDIO buffered I/O and standard I/O functions such as scanf( ) andprintf( ) can be used on fd.
system - run shell command
int system(const char *command);
The command is run noninteractively in a shell, output is to the terminal and your program waits for command completion. The main disadvantage with system( ) is that I/O bypasses your program unless you take steps to catch it.
popen - pipe to/from shell
FILE *popen(const char *command, const char *type);int pclose(FILE *stream);
Typically usage is: FILE *fp; char *command; /* command contains the command string (a character array) */ /* If you want to read output from command */ fp = popen(command,"r"); /* read output from command */ fscanf(fp,....); /* or other STDIO input functions */ fclose(fp); /* If you want to send input to command */ fp = popen(command,"w"); /* write to command */ fprintf(fp,....); /* or other STDIO output functions */ fclose(fp); The program cannot both send input to the command and read its output. The file fpbehaves like an ordinary STDIO file. Shell as a coprocessThe shell can be forked off as a child of the program and then commands can be both sent to it and the results can be read. More generally any other program could be run this way. There are a number of problems with this approach:First is the practical problem of keeping the processes in sync. For instance, can you recognizing when the coprocess has finished responding to a given request?Since the shell is receiving its input through a pipe and not through a terminal, it uses file not line buffering. It will not receive input until the buffer is full. Some solutions to this problem are:If you have access to the code for the coprocess you may be able to force line buffering or no buffering.Use a pseudo terminal to trick the coprocess into thinking it is connected to a terminal.Override the standard isatty( ) by dynamically linking in a version that always returns true. This will require altering the environment before calling the child coprocess, so that the child process's dynamic load library path includes the revised isatty. See isatty_preload.c for how to do this in SUN Solaris.Deadlock can occur if both processes write more than the pipe can handle. The parent may block during a big write, and so will not be able to read. This will block the child coprocess if it is also writes lots before doing a read.There are some alternatives. For example, a shell-like utility called expect can be used to programatically control a coprocess.
Similar questions