Writing to the standard input of a process
-
Then can you show the code where you use QProcess ?
-
Process creation ('QProcess* process' declaration is in a header file):
@process = new QProcess();
connect(process, SIGNAL(finished(int, QProcess::ExitStatus)),
this, SLOT(finished(int, QProcess::ExitStatus)));
connect(process, SIGNAL(started()), this, SLOT(started()));
process->setProgram("test.exe");
process->open();@Slots:
@void MainWindow::started()
{
qDebug() << process->write("test\n");
}@@void MainWindow::finished(int exitCode, Process::ExitStatus status)
{
qDebug() << "Finished";
qDebug() << exitCode;
}@ -
You are using QProcess in an unusual way (at least to me)
Since its a command line application, I would rather use the synchronous approach described "here":http://qt-project.org/doc/qt-5/qprocess.html#synchronous-process-api
-
Thank you, it helped - at least now I can get the response. I tried the following code:
@process = new QProcess();
connect(process, SIGNAL(finished(int, QProcess::ExitStatus)), this, SLOT(finished(int, QProcess::ExitStatus)));
process->setProgram("test.exe");
process->start();
process->write("test\n");
process->waitForFinished();
@Slot:
@void MainWindow::finished(int exitCode, QProcess::ExitStatus status)
{
qDebug() << "Finished";
qDebug() << exitCode;
qDebug() << process->readAllStandardOutput();
}@The code in the 'finished' slot is executed and prints the output produced by the called program (echoed "test"). The actual difference seems to be in the 'process->waitForFinished()' call. If I remove it, the C# program does not terminate (the created process remains in the list of processes).
The problem is than I need to execute it asynchronously from my GUI application, with a possibility for user to terminate it, so the GUI should remain responsive.
-
Does it also happen if you add waitForStarted before writing to it ?
-
Yes, adding process->waitForStarted() before process->write("test\n") does not change anything, the process does not terminate if there is no process->waitForFinished() line in the end. Closing (or not closing) the write channel has no effect in all cases.
-
I just forgot one basic question… What version of Qt are you using on what version of Windows ?
-
Qt 5.2.0 on Windows 7 Ultimate 64 bit, Service Pack 1.
I have tried to build my program using two compilers, MinGW 32 bit and MSVC2012 64 bit. The behavior is the same in both cases.
-
Does it also happen if you call a standard cmd command ?
-
I am not sure how to call a standard cmd command from a Qt application (I have tried process->setProgram("dir"), it runs but produces no output to stdout), but I did further research.
I wrote a simple program in C++ and compiled it with MinGW:
@#include <iostream>
#include <string>int main(int argc, char *argv[])
{
std::string s;
std::cin >> s;
std::cout << s << std::endl;
}@It works both with and without process->waitForFinished() call, my Qt application can write to its standard input and retreive echoed string from its output. Writing from a slot connected to the 'QProsess::started' signal also works. It seems that the problem is with my C# program after all.
-
Did you try with a similar minimal application written in C# ?
-
Yes, I have tried this:
@class Program
{
static int Main(string[] args)
{
string s;
s = Console.ReadLine();
Console.WriteLine(s);
return 0;
}
}@Works if I place waitForFinished() call after writing to the standard input of the process, but never terminates without it. Changing configuration of the C# program from Debug to Release in Visual Studio does not help.
-
Maybe a silly question (I don't know much about C#) but aren't you missing a "\n" here ?
-
No, Console.WriteLine() method inserts it automatically. And with waitForFinished() call it works even when I change Console.WriteLine() to Console.Write(), which does not insert a newline symbol.
-
Could there be some subtle difference on how the C# runtime uses stdin/stdout ?
-
Yes, it seems that there is some difference, but I am not a C# expert and I have no idea what it is. I will try a simple program compiled using Mono but for now, I think it is easier to send all data as command line parameters.
-
As long as it's clean and works, do what is best.
Happy Coding !
-
hi,
Did you apply the same technique as @A1exander_Z did ?
