|
|
Home » Extra libraries, Code snippets, applications etc. » C++ language problems and code snippets » capturing stdout/err/in of subprocess
capturing stdout/err/in of subprocess [message #1672] |
Mon, 13 March 2006 14:21 |
wilho
Messages: 19 Registered: February 2006
|
Promising Member |
|
|
Hi!
Just got the idea (meaning I haven't yet really done any reasearch) but; how complicated it would be create terminal emulator upp-control based on SDL?
Whats best platform-independent way to spawn subprocess and capture its output and feed its input? How to render ANSI with SDL reseived from shell/cmd?
I have none of SDL and only some c++ experience, so whats I'm really after is some understandable resources and maybe comments to make a conclusion if I'm able to begin with this.
|
|
|
|
|
|
|
|
|
|
|
Re: capturing stdout/err/in of subprocess [message #1705 is a reply to message #1703] |
Tue, 14 March 2006 12:04 |
|
mirek
Messages: 14105 Registered: November 2005
|
Ultimate Member |
|
|
Quote: |
You're right, I don't understand (though I was trying to respond to Wilho). But however, I'm curious. I've only used Linux terminal a little but like many people, I use cmd.exe a lot and I'm struggling to see where cmd.exe performs the echoing of user input you refer to e.g. if I do CL /?, the "CL" application is fed keys and does its own echoing (if any) - cmd.exe doesn't do the echoing. I would have thought any echoing is done by the application itself, via stdout.
|
void main() { getchar(); }
Start that. The program will stop, allowing you to enter the line of input characters. Now this "enter the line of characters" is that "echoing" I am speaking about. And, AFAIK, this is not done by program, but terminal (in any case, it is terminal responsibility that if you press backspace, last character is removed from the input line).
Quote: |
Any way, not to worry. I don't know how to build an atomic bomb either ...
|
Explaining to you always pays off... Usually it leads to solving the problem. I am not sure why, but it is almost a rule
Mirek
|
|
|
Re: capturing stdout/err/in of subprocess [message #1716 is a reply to message #1705] |
Wed, 15 March 2006 00:09 |
gprentice
Messages: 260 Registered: November 2005 Location: New Zealand
|
Experienced Member |
|
|
Quote: | void main() { getchar(); }
Start that. The program will stop, allowing you to enter the line of input characters. Now this "enter the line of characters" is that "echoing" I am speaking about. And, AFAIK, this is not done by program, but terminal (in any case, it is terminal responsibility that if you press backspace, last character is removed from the input line).
|
Wow, I never noticed that. (I don't write console programs much.)
I tried the following program (with Borland compiler on Win XP). If I run it, the first key that gets pressed doesn't get echoed but its numeric value does get printed, then I can press a bunch of keys that do get echoed (and backspace works just as you say) and when I finally press return, the program exits.
getch() is Borland extension (and kbhit) - I think VC has similar ones. I wonder why the first keypress doesn't get echoed. If I change getch() to getchar(), the first character and following characters (until I press return) do get echoed, after which the numeric value gets printed. Maybe getchar() hooks up to a blocking OS function that runs in "line buffer" mode and getch() doesn't run in line mode.
Graeme
#include <stdio.h>
#include <conio.h>
int main()
{
while (1)
{
if (kbhit())
{
printf(" yes");
int k = getch();
printf( "%d", k);
break;
}
}
getchar();
}
|
|
|
|
Re: capturing stdout/err/in of subprocess [message #1743 is a reply to message #1717] |
Fri, 17 March 2006 10:52 |
mr_ped
Messages: 825 Registered: November 2005 Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
I don't see problem with knowing if the subprocess is looking for input.
If it does, it must call "getchar()" and similar things, i.e. listen to the standart input. If you (as an console) own the standart input line, you will know when the subprocess listens to it, so you know when to echo the input.
I.e.
OS input -> your console listen to it, and fetch the input into internal buffer, which will be standart input for subprocess -> subprocess connected to input from your console.
I don't know how this should be done in C++ and Windows, but that's imho the proper model how it should be done.
The cmd.exe allows you to choose the input for the subprocess, so you can run the subprocess and feed him with input from file or from output from other process trough pipe, and the reason why it works is because it knows when the subprocess calls getchar(), so the whole file is not feeded to the subprocess right at the start, but it's sended char by char whenever subprocess asks for next one.
(actually having ability to redirect input/output is very important in unix world, as most of the standart tools are highly specialized, and to fullfill your task you need usually to chain several tools to produce the final result, like "ps | grep gcc" to see only gcc processes. So the "ps" tool does not need to contain some "filter" code, as the filter code is included in grep, etc...
|
|
|
|
|
|
|
|
|
Re: capturing stdout/err/in of subprocess [message #1760 is a reply to message #1755] |
Sat, 18 March 2006 01:01 |
lundman
Messages: 175 Registered: March 2006 Location: Tokyo
|
Experienced Member |
|
|
I must agree I am not quite following why you need to know if your pipe-child is listening or not. You'll know if the child has gone away (EPIPE). The whole line buffering and echo is a tty/terminal feature which you can disable with ioctl(), that is quite trivial.
But if you create pipes to your child you need not worry about linemode/echo as it is direct without the tty/terminal layer.
You can check the number of bytes buffered in the pipe, set the low and high water marks, and maybe even the process flags. But why?
In LiON, to make sure to be portable, and allow for the pipe to be in select() non-blocking loops (HANDLES can't be in select(), and nonblocking polling is hard if you want to work on Win95/98/Me), I had to create read/write threads to translate between HANDLE and SOCKET.
But it works well, the same code will spawn processes on Unix, as Windows, and talk to it. I had to implement fork() and execv() for Windows though.
|
|
|
Goto Forum:
Current Time: Fri Nov 01 00:27:14 CET 2024
Total time taken to generate the page: 0.01892 seconds
|
|
|