If I have a windows console program written with c++, is it possible to retrieve that program's standard output, while the program is running? And if not, what would be the best way to rewrite the program? I know I could output to files and continuously check those files for updates. Is there another way? Is there a better way?
There are some interesting articles in Code Project:
CommandLineHelper (C#)
Redirecting an arbitrary Console's Input/Output (MFC/C++)
Universal Console Redirector (MFC/C++)
Yes, if you start the program yourself:
in CreateProcess, you pass a STARTUPINFO where you can specify handles for SDIN, STDOUT and STDERR. Note that oyu need to supply all three once you specify the STARTF_USESTDHANDLES flag.
Also, the handles need to be inheritable (otherwise, the child process can't access them), so the SECURITY_ATTRIBUTES basically need to look at least like this:
SECURITY_ATTRIBUTES secattr = { sizeof(SECURITY_ATTRIBUTES), NULL, TRUE };
You could open handles to disk files that contain input and receive output. Alternatively, this can be Pipes that can be read / written incrementally while the console app is running.
If it is a ready console executable
you can allways redirect it output in a file like this:
c:> echo Some text > file
or
c:> program > file
If you mean this?
As your question is not exactly clear.
\\ into another program
Oh, Ok
But my first answer is also used to it.
As there is also another possibility like:
c:> program1 | program2
its make a "pipe" between console programs
program2 receive on it stdin what program1 throws to stdout
Its common old-aged Unix-way practice in console programs.
And in such way NO need to rewrite programs to specifically support it.
If you are only interested in the program's stdout, popen() makes this pretty simple:
FILE* program_output = popen("command line to start the other program");
//read from program_output as you would read a "normal" file
//...
pclose(program_output);
You'd most likely need to use pipes to achieve this, and since you're using Windows, here's a link to MSDN article with an example that seems to do exactly what you wanted.
Related
I'm developing an interactive program that takes inputs from the user (through stdin) and outputs data accordingly (using stdout). While the program is running I need to open a background application (and leave it running while the main program is running). I have successfully done this using popen (using the "r" mode), however at times I get stdin conflicts. For example when the user enters an input intended for the main program, sometimes, the program treats it as an input to the background program. The user should never have to interact directly with the background program. Is there a way to completely decouple both the input and the output of the background program from stdin and stdout, while still being able to read and write using a file descriptor to the background process?
Just code exactly what you need. The popen function is a convenience function that you can use what it happens to do exactly what you happen to need. Otherwise, use pipe, fork, dup2, close, and whatever exec-family function you want.
You may find it helpful to look at a few implementations of popen/pclose to see how they work. Adjust as needed.
Simply don't use popen. Instead, use fork + one of the exec family of functions, which doesn't connect the io streams.
like in the title I was wondering whether is it possible to pass an input by use of redirection operators in CreateProcess(). I tried something like the following:
CreateProcess(NULL, "%ComSpec% /c c:\\somebatch.bat", NULL, NULL, ...);
where somebatch.bat contained c:\app.exe < c:\input.txt and it didn't pass the input, just launched the app.exe. On the output it said that:
c:\working_directory> c:\app.exe < c:\input.txt
c:\working_directory>Not enough storage is available to process this command.
(messing with irpcstack didn't help)
Are you guys aware of any magic trick that would allow me to do what I want without messing with the hStdInput pipe, which saying frankly I wanted to avoid. Cheers.
It has been a while since I have done this, but you have to set hStdInput member in the STARTUPINFO struct passed in as the next to last argument of CreateProcess. I'm pretty sure that there is no other good way to do this. Using hStdInput is pretty easy, open the file that you want to use as input, set hStdInput to the file handle, create the process, and close the handle.
You might be able to open the input file, duplicate the handle into the current processes standard input, and then create the process with bInheritHandles set to TRUE. Then your program will simply receive the file contents via stdin. I've never tried this in Windows, but it is common practice on UNIX based platforms.
As for running a batch file, read the comments in the MSDN entry for CreateProcess. I think that you have the arguments messed up.
Is there any reason you need CreateProcess?
The system function uses the default shell (so you wouldn't need to put in %ComSpec%) which means that redirection would work fine. It's also easier to use and more portable. If you're just going to wait for the process to finish, consider using system instead.
I have a program that executes various shell commands via system() and occasionally prints to cout. I want to redirect all output coming from system() calls to a log file so they don't clutter up the normal output. Can I do this without having to append > log to all my system commands?
Looks like you can use popen
Close the stdio file descriptors (0, 1, and 2) and re-open them on whatever output device you like.
Using system is just a bad idea, period. If you use fork and execve or posix_spawn, you can easily make the necessary redirections and avoid all sorts of vulnerabilities from shell quoting issues.
If you can use a library that wrap process call. It is hard to code from posix. I use boost.process, it works fine. you can simply tell the lib how you want the output to be redirected...
my2c
How to output in buffer console output? For example I just need output of command "ipconfig -all", and want to store that information in some buffer?
You can write the output of a console application to a file (at least, in Windows), using the > parameter.
For example, for your case you'd write ipconfig -all > C:\output.txt to write the information to output.txt.
Alternatively, if you're doing it in code, you could create a process that runs ipconfig, and read the standard output using Microsoft's convoluted methods http://msdn.microsoft.com/en-us/library/ms682499%28VS.85%29.aspx, or an application framework such as Qt, which simplifies process management http://qt.nokia.com/products/ - see QProcess: http://doc.qt.nokia.com/4.3/qprocess.html#readAllStandardOutput
It seems you have an XY problem
What you really want to do is capture the output of another command. The whole "buffer" part is your first stab at an answer. It doesn't help you, and in fact it got you stuck thikning in the wrong direction.
badgerr offers some solutions, but the most common solution is popen("ifconfig -a", "r"). This doesn't return a buffer, it returns a FILE* that you can pass to fread. It's a POSIX function and available on Linux.
On Windows, you call CreateProcess and pass a STARTUPINFO structure containing dwFlags=STARTF_USESTDHANDLES, and hStdOutput=ResultOfCreatePipe.
I have a project that I thought was going to be relatively easy, but is turning out to be more of a pain that I had hoped. First, most of the code I'm interacting with is legacy code that I don't have control over, so I can't do big paradigm changes.
Here's a simplified explanation of what I need to do: Say I have a large number of simple programs that read from stdin and write to stdout. (These I can't touch). Basically, input to stdin is a command like "Set temperature to 100" or something like that. And the output is an event "Temperature has been set to 100" or "Temperature has fallen below setpoint".
What I'd like to do is write an application that can start a bunch of these simple programs, watch for events and then send commands to them as necessary. My initial plan was to something like popen, but I need a bidrectional popen to get both read and write pipes. I hacked something together that I call popen2 where I pass it the command to run and two FILE* that get filled with the read and write stream. Then all I need to do is write a simple loop that reads from each of the stdouts from each of the processes, does the logic that it needs and then writes commands back to the proper process.
Here's some pseudocode
FILE *p1read, *p1write;
FILE *p2read, *p2write;
FILE *p3read, *p3write;
//start each command, attach to stdin and stdout
popen2("process1",&p1read,&p1write);
popen2("process2",&p2read,&p2write);
popen2("process3",&p3read,&p3write);
while (1)
{
//read status from each process
char status1[1024];
char status2[1024];
char status3[1024];
fread(status1,1024,p1read);
fread(status2,1024,p2read);
fread(status3,1024,p3read);
char command1[1024];
char command2[1024];
char command3[1024];
//do some logic here
//write command back to each process
fwrite(command1,p1write);
fwrite(command2,p2write);
fwrite(command3,p3write);
}
The real program is more complicated where it peeks in the stream to see if anything is waiting, if not, it will skip that process, likewise if it doesn't need to send a command to a certain process it doesn't. But this code gives the basic idea.
Now this works great on my UNIX box and even pretty good on a Windows XP box with cygwin. However, now I need to get it to work on Win32 natively.
The hard part is that my popen2 uses fork() and execl() to start the process and assign the streams to stdin and stdout of the child processes. Is there a clean way I can do this in windows? Basically, I'd like to create a popen2 that works in windows the same way as my unix version. This way the only windows specific code would be in that function and I could get away with everything else working the same way.
Any Ideas?
Thanks!
On Windows, you invoke CreatePipe first (similar to pipe(2)), then CreateProcess. The trick here is that CreateProcess has a parameter where you can pass stdin, stdout, stderr of the newly-created process.
Notice that when you use stdio, you need to do fdopen to create the file object afterwards, which expects file numbers. In the Microsoft CRT, file numbers are different from OS file handles. So to return the other end of CreatePipe to the caller, you first need _open_osfhandle to get a CRT file number, and then fdopen on that.
If you want to see working code, check out _PyPopen in
http://svn.python.org/view/python/trunk/Modules/posixmodule.c?view=markup
I think you've made a very good start to your problem by using the popen2() function to abstract away the cross-platform issues. I was expecting to come and suggest 'sockets', but I'm sure that's not relevant after reading the question. You could use sockets instead of pipes - it would be hidden in the popen2() function.
I am 99% sure you can implement the required functionality on Windows, using Windows APIs. What I cannot do is point you to the right functions reliably. However, you should be aware the Microsoft has most of the POSIX-like API calls available, but the name is prefixed with '_'. There are also native API calls that achieve the effects of fork and exec.
Your comments suggest that you are aware of issues with availability of data and possible deadlocks - be cautious.