Catching another program's output?

[kenpem]

Hi folks

I've been a developer for almost thirty years now (OMG am I really that old?), but have never really done much in C. Finally now I have a project where I can't avoid it

The platform is a LinkSys NSLU2 "Slug", running uNSLUng V2.3R63-uNSLUng-6.8 to HDD, with a Velleman K8055 interface board hanging off a USB port, and I'm writing code to interact with the outside world through this board. Running GCC v3.3.5.

So far, so good. I found a command-line binary for the K8055 which works great - you give it a command an it returns a line of text to the console, telling you what state all the inputs are in. Like this:

$ k8055 -P:2 -D:64
11;0;134;136;0;0

Obviously my control code needs to know what the output was. I've solved the problem by sending the output to a file, rather than the stdout console:

$ k8055 -P:2 -D:64 > status.txt

then opening and reading that file within the code. And this works. It just seems very clunky, not to mention horribly slow.

Is there a way I can call that external program, and catch its output, without going via a file? Sorta..... route THAT programs stdout to stdin so that I can grab it?

Just to make life really interesting... the control program (my code) runs as a service, although I'm negotiable on that if it gets in the way.

I'd also eventually like to re-mash the K8055 code and incorporate it into my own stuff, but right now I can't even compile it (dependancy issues?), and I'll save that one for another day. Right now I'd be happy just to dump the text-file-route I'm currently using.

[kenpem]

In case I wasn't really clear.... this is what the code is currently doing:

   sprintf(cmd, "/home/dev/test1/k8055 -P:2 -D:%d > /status.txt", value);
   system(cmd);
   fr = fopen ("/status.txt", "rt");  /* open the file for reading */
   fgets(cmd, 255, fr);
   fclose(fr);

( "cmd" is a char[255] )

so by the end of this lot, the output of the k8055 program is loaded into variable cmd. All I'm looking for here is a more efficient way of doing this.

[MacGyver]

Something like popen() might be what you want.

[kenpem]

Thanks Mac, that might be exactly what I was looking for! Off to play...

[kenpem]

WAY COOL! popen() is just what we needed. TVM, MacGyver.

Guess I need to go shopping for a good C reference.... I've put it off long enough!

[IceDane]

WAY COOL! popen() is just what we needed. TVM, MacGyver.

Guess I need to go shopping for a good C reference.... I've put it off long enough!

Shopping? Pff, this is the internet. Best C reference there is

[kenpem]

Shopping? Pff, this is the internet. Best C reference there is

...as illustrated by the tip I got about this one.

But I'm old enough to still get value out of a decent book. And enough of a nerd to read one cover-to-cover to make sure I didn't miss anything important. Like popen().

[IceDane]

...as illustrated by the tip I got about this one.

But I'm old enough to still get value out of a decent book. And enough of a nerd to read one cover-to-cover to make sure I didn't miss anything important. Like popen().

The man pages(Which you can find online, too) and various user-made references on the internet are quite sufficient in my opinion. But yeah, sometimes having it on hardcopy is just better, I know.

[matsp]

One of the problems when searching for a function that you don't know the name of is that you don't know what to search for (searching for "catching another program's output" may not get you directly to the right subject, because you'll find lots of references for redirected output to files in the first 1000 or so google hits).

--
Mats

[kenpem]

One of the problems when searching for a function that you don't know the name of is that you don't know what to search for (searching for "catching another program's output" may not get you directly to the right subject, because you'll find lots of references for redirected output to files in the first 1000 or so google hits).

--
Mats

Yep, that's exactly why I'm a fan of the cover-to-cover approach. And forums like this, of course! Google was no help at all in helping me solve this problem, other than (eventually) finding the forum.

Still, all's well that ends well, so let's not start an argument about the value of printed references!