@jsulm I tried QChar to convert unicode and my problem solved. now qDebug prints the text correctly. 👌🏻 I also copied the readAllStandardOutput() to a QString and removed backslashes via remove("\x5C\x75").

Thanks guys it worked. python3 and readyReadStandardOutput(showed the log ,was expecting it to work like qDebig() and cout .My bad) . Sorry for bothering with wrong misconception.

@Christian-Ehrlicher, @JonB I deployed the two programs again and had the same problem as before. Then I went through all the deployed .dll's and there were some missing. I copied them inside the folder manually and now it works. So the problem was windeployqt or some missing windeployqt-commands while deploying. Thank you again, I'll close this topic now.

@JonB Hi, thanks for all the help, I finally figured it out, it did have to do with the env variable for structureanalysis, even if I ran it inside cmd there was trouble. I had to send the full path for where structureanalysis is located in my shell script. it worked

@SameerK If it's repeatable you can raise a bug report for it. They will want as small a piece of code for the UI as possible. Pick something standard under Linux for the command (sleep might be suitable).

@Saviz For the questions about what command line arguments you might want to pass to it you might be better asking in a forum for ffmpeg. When running a command whose output you are interested in you should always read both standard output and standard error. If you do not need to process them separately you might use QProcess::MergedChannels. But not if you need to parse them distinctly. If you want the output you show, and ffmpeg does not offer this, parse the output to produce what you want.

@DungeonLords What is your question? Your code runs a bash -c "....", which is fine. Your linked output shows libGL errors. What happens if you run ffmpeg -y -f lavfi -i testsrc=size=1280x720:rate=1:duration=10 -vcodec mjpeg -pix_fmt yuvj422p -f mjpeg input.yuvj422p from a shell? If that errors what is the relevance of Qt or QProcess?

@JonB In command line, we usually kill a mpi program by killing one of the child processes. And I find this may be a bug of intel mpi on windows [ https://community.intel.com/t5/Intel-oneAPI-HPC-Toolkit/InteloneAPI-MPI-2021-2-0-behavior-on-Linux-and-Windows-differ/td-p/1290020 ]. Anyway, thanks for your reply.

@Dariusz said in QProcess not printing "live update" from cmd: sftp sends messges like But (so far as I can see) you know it does that only when output is attached to a terminal/console. Which their code may be testing for, and not sending if not. Because there is no \n, the qt does not trigger any signals. Not byteavailable or anything really as far as I can tell. The presence or absence of \n will not itself affect whether Qt/QProcess sees or receives bytes. It might be an indication that it is not being flushed immediately, but that is a different matter. I take when we self.process.setProcessChannelMode(QProcess.ForwardedChannels) he then get console somehow? I believe that attaches the QProcess's output to the output of the Qt program, which is a console/terminal. Which as I say may be why in that case, and only that case, you see the output. But then you won't be able to "capture" it. Can you link me to post/text? I'm blind :- ( Principal among these was Try running your sftp from a Command Prompt but with all its output redirected to a file. When it has finished what is in that file, any "status messages"? You should test something like: sftp < file_of_input_commands > some_file If you can also redirect Windows/DOS/cmd stderr that would be even better. Like under Linux it would be sftp < file_of_input_commands > some_file 2>&1 but I can't recall whether/how you can do that 2>&1-type thing with Windows. Test without that anyway. The point here is that output should not be left to go to console. This is close to simulating what is going on when you have another program --- Qt or not --- running a sub-process with redirection. I have a hunch this will show that in this situation you do not get the "update" messages, because sftp program detects the output redirection and does not issue them in this case.....

@camtheman99 That is interesting, thanks to @Christian-Ehrlicher.

Hi, You can open a feature request to discuss that matter.

@BigBen said in QProcess not working in QT Creator (using qt version 6.3.0): However, p->startCommand("dir C:\\Users") gives me no error and no output. Well that is interesting. As I said I only just discovered looking at the docs. It's new in Qt 6.0. I do not use Qt 6, nor Windows, so I cannot comment. If you look at he examples at https://doc.qt.io/qt-6/qprocess.html#startCommand you can see them claiming to issue dir commands that way, that's all I can say. I want to ask that in p->start("cmd", { "/c", "dir C:\\Users" });, what does the /c mean in the second argument? The Windows/DOS cmd.exe takes various arguments, as you can see from running cmd /?. Including: /C Carries out the command specified by string and then terminates Basically without the /c it runs an interactive Command Prompt, the command-line console. With the /c it interprets and executes the command line string following it, i.e. your dir .... It does not open a Command Prompt window and it returns to your code immediately after executing the command. dir is built into cmd.exe --- along with many other "simple" commands like echo or mkdir --- there is no external dir.exe file to execute, so we need cmd /c dir to perform it.

I solved it, the makefile contains this command as well: flex MyLanguage.l and in the OS there is two intalled flex, Qt used the wrong one.

Looks like using the QProcess::stateChanged signal (and removing terminate()) works. It uses QThread::msleep() so its not ideal, but its fine for me. HWND myHWND; static BOOL CALLBACK enumWindowCallback(HWND hWnd, LPARAM lparam) { DWORD pid; GetWindowThreadProcessId(hWnd, &pid); if (pid == lparam) { myHWND = hWnd; return FALSE; } return TRUE; } ProgramStarter::ProgramStarter(QObject *parent) : QObject{parent} { QProcess *qpr = new QProcess(this); connect(qpr, &QProcess::stateChanged, this, [=](QProcess::ProcessState newState){ if (newState == QProcess::Running) { QThread::msleep(250); EnumWindows(enumWindowCallback, qpr->processId()); } }); QString executable = "C:\\path\\to\\program.exe"; qpr->start(executable); qDebug() << myHWND; }

$ /usr/sbin/getcap /bin/ping /bin/ping cap_net_raw=ep This work because /bin/ping have capabilites https://man7.org/linux/man-pages/man7/capabilities.7.html CAP_NET_RAW Use RAW and PACKET sockets; bind to any address for transparent proxying.

@JonB Thanks. I like the QStandardPaths::StandardLocation but I did a deploy and after that I put just everythink in the folder with the *.exe file like @eyllanesc suggested and it works fine. I think my problem was that i missunderstood QProcess. I thought it is just a trigger to start the program and it is only important to know, where the path of the .py is. But thanks guys anyway :-)

@Sina-Ranjkesh-zade said in Converting QByteArray to QString: For "standard input" if you mean input arguments of the process, I got this error: No, I meant standard input. That is , the python program reads from a terminal and accepts input just as if you typed it (except it is the Qt program sending that input). The Qt program can send a command to the python program, send the data it needs, and read the result (if there is one) back on the python program's standard output. Or you can used shared memory, or a socket, or files, or do whatever the python program is doing in the Qt program...

@aliemrenebiler said in Run a terminal command with a button click: QProcess is not working, the program never opens and says as output "QProcess: Destroyed while process ("...") is still running.". The problem would appear to be that your QProcess object goes out of scope (is destroyed) while the process you asked it to launch is still running i.e. exactly what the error message says. This is most likely because you have create the QProcess on the stack in the slot handling your button click, but it could be because it is parented to another QObject that is destroyed. We can only guess without seeing your code.

@JKSH ,thanks,I find that this happens when debugging, not when publishing。