I have a Windows program running under Wine. That Windows program lets me set up "tools" to run external programs and then it will capture their standard output/error and show it to me within the Windows program's interface.

I want to be able to run a native Linux program as such a tool. I am able to get my Windows program to run a Linux program, but it doesn't get access to the output. Instead, the Linux program's output is shown in the console window from which I ran the Windows program.

My specific program is EditPad Pro, a text editor, but I would like if possible a solution that works for any Windows program that runs external programs. (Many text editors have such a feature, for instance, to be able to compiler/run the source code being edited.)

As an example, I tried to run /usr/bin/python3 --version as an external tool, to test things. I open an ordinary linux terminal and do wine myprogram.exe. Within Myprogram, I set up /usr/bin/python3 --version as an external tool. (I have also tried using start /unix ahead of this but that didn't work either.) When I run the tool, the Python version information is displayed in the linux terminal where I typed wine myprogram.exe. Myprogram sees no output from Python. But I want that output to be going to "Myprogram", which is the one running it, not to the linux terminal that launched Myprogram.

How can I achieve this?

  • 1
    How do you exactly run /usr/bin/python3 from your program? Oct 23, 2020 at 4:25
  • @EduardoTrápani: I specify the command line in the GUI of my program. I don't know exactly how it's running it, although if you have ideas of how I can find out more about that that could be helpful. I assume it is using some kind of system call to run my specified command (python3) as if it were being typed on the Windows command line. I note that I get the same behavior if I try to run python3 from within a wineconsole, so I'm guessing something similar is going on with my program.
    – BrenBarn
    Oct 23, 2020 at 5:32
  • I thought that, since you were trying to capture stdout, you had access to the code. Who would consume stdout then? Oct 24, 2020 at 18:04
  • @EduardoTrápani: It is as I said: I specify a command line within "Myprogram" and say "run this command line as an external tool". Myprogram runs whatever I tell it to, and Myprogram captures the stdout and shows it to me in the interface of Myprogram. It is like a typical IDE/Editor feature where the editor allows you to run external tools (such as compilers) and see their output/errors within the editor.
    – BrenBarn
    Oct 24, 2020 at 19:12
  • Can you tell us the name of this MS program? Maybe someone has solved the exact problem. Jan 2, 2021 at 9:58

1 Answer 1


From what you say, I see no evidence that the MS program is capturing the stdout of the external tool: If the stdout is appearing in the terminal that launched the MS program ("Instead, the Linux program's output is shown in the console window from which I ran the Windows program."), then this indicates that the external program is inheriting stdout from its caller.

You need to find a way in your MS program to get it to read the data. Look to see what options it has:

  • Does it have an option to read stdout of the external tool.
  • Does it have a way to read a file, and to string command together.
  • It does have an option to read stdout of the external tool, and that's what I'm using. The external program is not inheriting stdout because the Windows program has several options for what to do with the output (ignore it, put it in a new file in the editor, etc.) and those options work in Windows, so it's clear the Windows program is able to access the output of the external tool. I think the problem is that Wine is inheriting stdout (or messing it up somehow) so that the Windows program does not have access to a real stdout stream for the external tool.
    – BrenBarn
    Jan 2, 2021 at 19:35
  • Also, if I do wine cmd to get a windows command prompt in a terminal, and then do /bin/echo helloat that windows prompt, the output shows up after the following windows prompt, indicating that windows is not waiting for the output of echo before going back to its own prompt.
    – BrenBarn
    Jan 2, 2021 at 19:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .