Extracting output from system(3) call

V

v4vijayakumar

if possible to use pipe(2) how could file descriptor can be derived
from file pointer, FILE *. TIA.
 
R

Robert Harris

v4vijayakumar said:
is there any standard way to extract output from system(3) function?
TIA.

<OT>
In a Posix system, use popen(3) instead
</OT>

Robert
 
?

=?ISO-8859-1?Q?Martin_J=F8rgensen?=

Robert said:
<OT>
In a Posix system, use popen(3) instead
</OT>

BTW: What is Posix???


Best regards / Med venlig hilsen
Martin Jørgensen
 
S

SM Ryan

# is there any standard way to extract output from system(3) function?

You have to save the output to a file within the command line,
and then open the file subsequently.
For example on unix, you can do something like
if (system("cat gloober/* >fripper")!=0) error(...);
FILE *fripper = fopen("fripper","r");
...
fclose(fripper);

POSIX systems also provide popen/pclose.
FILE *fripper = popen("cat gloober/*","r");
...
if (pclose(fripper)!=0) error(...);
 
V

v4vijayakumar

It seems that there is another way.

fclose (stdout);
stdout = fopen ("standard-output-file", "w");

system("ls");

/* process output file here */
 
F

Flash Gordon

v4vijayakumar said:
It seems that there is another way.

Another way to do what? Google is most definitely *not* Usenet, just an
interface that dupes people in to making incorrect assumptions. Read
http://clc-wiki.net/wiki/Intro_to_clc and provide context in future.
fclose (stdout);
stdout = fopen ("standard-output-file", "w");

system("ls");

/* process output file here */

I've got no idea what you think the above will do, but I doubt it will
actually do what you think. For a start, there is no guarantee that
changing stdout within a program will affect where the output of a
program invoked using system goes.
 
S

SM Ryan

# It seems that there is another way.
#
# fclose (stdout);
# stdout = fopen ("standard-output-file", "w");
#
# system("ls");

You're inferring a relation between a program's FILEs and
the files of whatever kind of process system(...) uses.
It's possible no such relation exists.
 
V

v4vijayakumar

stdin, stdout and stderr are 'FILE*' and they are associated to the
particular program in execution. don't see any problems in fclose/fopen
these streams.

the following lines are from `man 3 stdin`.

" Under normal circumstances every Unix program has three streams
opened for it when it starts up, one for input, one for output, and one
for printing diagnostic or error messages. These are typically attached
to the user's terminal (see tty(4)) but might instead refer to files or
other devices, depending on what the parent process chose to set up.
(See also the ``Redirection'' section of sh(1) .)"
 
J

Jordan Abel

stdin, stdout and stderr are 'FILE*' and they are associated to the
particular program in execution. don't see any problems in fclose/fopen
these streams.

How do you propose to fopen stdin, when there is no FILE * parameter to
fopen()?
 
V

v4vijayakumar

Jordan said:
How do you propose to fopen stdin, when there is no FILE * parameter to
fopen()?

#include <stdio.h>
FILE *fopen(const char *path, const char *mode);
 
F

Flash Gordon

v4vijayakumar wrote:

Please provide context... oh wait, I already asked that. I'll assume you
posted pefore seeing that message, but I know it has reached Google now
so you have no further excuse for not providing context.
stdin, stdout and stderr are 'FILE*' and they are associated to the
particular program in execution. don't see any problems in fclose/fopen
these streams.

Nothing wrong with closing them, potentially nothing wrong with opening
it them on a file.
the following lines are from `man 3 stdin`.

" Under normal circumstances every Unix program has three streams

That should be your first clue that it is not necessarily true on all
systems. Unix is not C so whatever is defined for Unix is defined for
Unix and not necessarily all, or even all common, C implementations.
opened for it when it starts up, one for input, one for output, and one
for printing diagnostic or error messages. These are typically attached
to the user's terminal (see tty(4)) but might instead refer to files or
other devices, depending on what the parent process chose to set up.
(See also the ``Redirection'' section of sh(1) .)"

What makes you think closing stdout/stdin/stderr and then opening it on
another file actually redirects it for processes you launch with system.
C streams are a high level concept and there is no reason to assume that
opening stdout on a file will affect the low level stuff like the file
descriptors 0, 1 and 2 that Unix uses, after all you have not told fopen
that it is to be associated with one of those file descriptors!

Note, discussion of file descriptors is off topic here, I merely mention
them as one possible way things could be implemented.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
 
F

Flash Gordon

v4vijayakumar said:
#include <stdio.h>
FILE *fopen(const char *path, const char *mode);

I suspect that Jordan knows the prototype of fopen so I doubt that
answers his question. The question being one for you to think about.
consider the following code fragment:

int i=1 ,j=4;
int *p = &i;
p = &j;

What effect does the final statement have on i? What effect on j?
Importantly, will j not be 1? That is the sort of thing you are trying
to do.
 
K

Kenneth Brody

v4vijayakumar said:
It seems that there is another way.

fclose (stdout);
stdout = fopen ("standard-output-file", "w");

system("ls");

/* process output file here */

stdin/stdout/stderr are not l-values.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>
 
F

Flash Gordon

Kenneth said:
stdin/stdout/stderr are not l-values.

C&V? For information, not because I disbelieve you. I thought that was
the case, but when answering the question I tried to find that in the
standard but couldn't.
 
K

Kevin Bagust

Flash said:
C&V? For information, not because I disbelieve you. I thought that was
the case, but when answering the question I tried to find that in the
standard but couldn't.

I can only find it mentioned in footnote 230 in C99, which is associated
with the description of the freopen function (7.19.5.4). The foot note says:

The primary use of the freopen is to change the file associated with a
standard text stream (stderr,stdin, or stdout), as those identifiers
need not be modifiable lvalues to which the value returned by the fopen
function may be assigned.

Kevin.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top