# input/output

This is a discussion on input/output within the C Programming forums, part of the General Programming Boards category; hello, I have a .exe (in windows) that only works in the command line, and I was wondering how I ...

1. ## input/output

hello,

I have a .exe (in windows) that only works in the command line, and I was wondering how I could redirect intput/output to send a string to the exe and receive the output.
note: for each input sent there might be zero, one or more outputs, spread out in time.
I would like to know what's the whole procedure, including the part where the .exe is called/exited.

Thanks

2. That depends where you are trying to send the string from and receive the output back to...

3. Not quite sure what you mean, but if you want to force the Command Prompt to stay open until you press a key, append these lines to your code.

Code:
#include <stdlib.h>

int main() {
/* code code code... */
system("pause");
return 0;
}
Or if you want to redirect your program's output to file called, say, "OUTPUT.TXT", write a batch file.

Code:
/path/to/exe/file/prog.exe > OUTPUT.TXT
Then, just double-click on your batch file to execute the program at C:\path\to\exe\file\prog.exe and your output will be written to C:\path\to\exe\file\OUTPUT.TXT, if not ./OUTPUT.TXT.

4. I'm sorry for having explained myself poorly as you didn't understand what I meant.
I don't want to pause the system in the end, nor do I want to redirect the output to a file.

What I want is to be able to interact with that executable, within my C code (programmatically), as I would have done as a user.
That means that I want to be able to send commands to that executable from my C code, and I want to receive the output in some way that the C code can understand and parse and do whatever needs to be done with the output. The executable is not to be closed between two commands sent, it is to be opened during the whole conversation (as it would be with a normal use, when used with the command line prompt - except that when I use it from the C code, I don't want the user to see the command prompt of that executable).

5. I'm sorry I have explained myself poorly as you didn't understand what I meant.

I don't want the command line prompt to stay opened in the end of the execution, nor do I want to redirect the output to a file.

What I want to do is to be able to use a executable, which is normally used with the command line prompt, inside my own C code. So that means that I want to be able to send commands to that executable and receive the output (which can come in several pieces, one at a time and sometimes long after the input was sent; just like when humans talk, they can speak more than one sentence at a time, both of them, not necessarily answering to a question). The executable must remain running during the whole conversation. (interprocess communication, a pipe I guess would be the best solution, but I'm not too familiar with that, especially in windows, so I would like you to show me the code I could use to achieve that). I would like to know how to create it (the process + the communication) and how to kill it when I'm done as well.

Thanks.

edit: oh sorry about the double post, I had received a database error but apparently it worked nonetheless. I'm leaving the two messages so that you can understand better what I mean and compare if necessary.

6. On windows... forget it.

7. Come again?

8. Again, go read MSDN. Learn to use the resources readily available instead of begging people to give you code.

9. Originally Posted by chris04585
Come again?
What I said...

Windows programs run independently of one and other. There is no real way to communicate between them... and in a great many cases steps are taken to prevent it.

You aren't going to run a program, remotely feed it data and get it's data fed back to you... *Unless* it has been specifically programmed for that task.

Really... just think of the horror viruses would be if a program could simply take over the user interface of another program... It's just about the biggest security hole imaginable.

10. Well yes, it has indeed been programmed for that task. I just don't know how to implement it (and no, there's no documentation as to how to do it).
All I want is to redirect the stdin/stdout so that I can use it inside my C program. One way would be to use prog.exe > OUTPUT.TXT <input.txt, and open these text files to write to input and read from output, but that doesn't seem very efficient, which is why I said I was not interested by that solution. Besides, I don't think that with that solution I would be able to give more input without having to kill and rerun the executable (the input file is probably read only once?). I need something more like a "tunnel", where I can give data whenever I want, and receive it as soon as there's something to receive.

11. Ok, well, good luck with that...

12. Can someone help me to do that please ?
I think that this code (http://www.erack.de/download/pipe-fork.c) would suit my needs, but I'm not sure because I'm not a programming expert (in your opinion, is it ?). Plus, it seems to use some functions that can't be used in windows, so if you think that this is the solution, then could you help me to translate it to windows ?

Thanks.

13. I'll take a look at it, but straight up, you can't "tunnel" from one windows program to another one.

You CAN run the exe program, from within your own program, or from a bat file, over and over, as much as you want (assuming the windows program is well written). AND, when you start the exe, you can feed it input from redirection, and output too.

But you know that.

You'll never have the flexibility of input and output that you would have if you had your own source code which could be modified for this. That can't happen, imo.

I looked at the program you linked to - very nice looking (couldn't run it, it's a Linux program). Since I just began working with a Window compatible IDE and compiler, I'm not able to tell you how much of that you can do in a Windows program. That kind of programming is not a part of C, but of using the OS (Linux or Windows).

If you can't find your answer in our Windows forum, then I'd take parts of this program, and ask this question (along with the parts of the program), in one of the MSDN monitored web support sites (for Visual C/C++ preferably).

I'm getting this gut feeling that you could do better by writing your own program, and forgetting this "tunnel to another program" idea. In C, what you want could be done in a simple function call or calls.