Windows stdout writes directly to console and cannot be captured

[usbhub]

• Electron version: 0.36.7
• Operating system: Windows 7

On Windows when writing to process.stdout it does not actually write to stdout, instead it writes directly to the console. This is very confusing and had me banging my head against the desk thinking there was something wrong with my C# code which was launching electron and trying to read from stdout, receiving an empty string always even though I could see the output in the console.

Eventually I found this related issue: #683 which points out how Windows GUI apps cannot read/write from stdout easily. The issue was closed as "I don't think this can be fixed." but there is the workaround as others were mentioning involving having a separate delegate executable to use a named pipe to pass output from the GUI app to a console app:
http://stackoverflow.com/questions/54536/win32-gui-app-that-writes-usage-text-to-stdout-when-invoked-as-app-exe-help
I see that in the code you are using AttachConsole https://github.com/atom/electron/blob/master/atom/app/atom_main.cc#L103
But if you replaced this with setting up a named pipe as is shown in this project:
https://code.google.com/archive/p/dualsubsystem/
Then you could have stdout working.

Are there any plans to implement this? Otherwise I think the only option is for me to read from / write to a temporary file. At the very least it would be good if there were some clear documentation or warning about this so people aren't confused when they can't read from stdout.

[mkozakov]

+1

[zcbenz]

You can implement the same thing by redirecting process.stdout to a named pipe with JavaScript, it doesn't have to be integrated into Electron.

[usbhub]

It seems that node does not explicitly have named pipes, though you can use the net module's sockets: http://stackoverflow.com/a/18226566 . There also seems to be an easy to use third party package: https://www.npmjs.com/package/named-pipes .

That being said this is not the issue. Yes I could use a named pipe or a socket or a local file, but the problem is that the standard streams are not working as one would expect. I understand that this is not really Electron's doing and it is more a fault of Windows for not properly supporting standard streams on GUI applications, but there is a common workaround used in many other applications that could also be implemented here and documented to solve the issue and save devs the hassle of always setting up a totally different workflow for windows. Also imagine if I just want to do simple command redirection on the windows command line, I cannot create a named pipe there and it will just write directly to the console instead of to a file for example, which is confusing at best. The bottom line is I cannot use the standard streams which seems like missing functionality.

The fact that I call process.stdout.write or process.stderr.write on windows and it doesn't actually write anything to the streams I think is problematic enough that it deserves a fix. If you do not have the capacity to work on it then I will try and implement it myself when I have some time, but I think this issue should not be closed.

[zcbenz]

You can set the ELECTRON_NO_ATTACH_CONSOLE environment variable to disable console attachment, we are doing things in current way because most developers just want to have the output in console don't care about stdout. I don't think changing current behavior for uncommon use cases is a good idea.

The named pipe way is used by dualsubsystem which is mentioned in your comment, it works by redirecting output to named pipe, and then use a console program to read the named pipe and print data to stdout.

[mkozakov]

I totally agree with the op. The fact that process.stdout.write doesn't actually write to stdout, but shows up in the console is misleading, and caused me a lot of time to figure out.

[usbhub]

Yes I know you can set the environment variable to not attach to the console, and I think it is debatable whether it should be disabled by default with the current stdout behavior to avoid confusion. I wouldn't call reading from stdout as an "uncommon use case", especially since if I understand correctly Electron is supposed to be a generic cross platform UI framework for all types of applications. Many applications will want to interact with other processes, and if you want to communicate with other processes the standard streams are a very, well standard way to do so.

I know that the project I linked uses named pipes, I mentioned it in my first post. I am not saying to avoid named pipes, they should be used. I am saying that between the options of all windows devs who want to interact with Electron having to set up named pipes in their projects vs Electron implementing it once and then the standard streams working for all devs, I think the latter option is better. Given that the standard streams are supported properly on the other main Electron platforms it only makes sense to support it on windows as well, yes it is a bit awkward on windows with the separate console executable and yes it will take a bit of extra code in Electron, but it will collectively save those using Electron much more code.

If the goal of Electron is to make cross platform UI development easy then I think the same standards should be kept across all platforms as much as possible, especially something as basic as accessing standard streams. If I can write "process.stdout.write" on mac and linux and it works then I should be able to assume that it will work on windows as well, I shouldn't have to write if (platform == "win32") and then set up a named pipe just because I am on windows.

[joaomoreno]

Wow. Didn't know about ELECTRON_NO_ATTACH_CONSOLE. This solves some of VS Code's problems.

[tedbrandston]

Just wasted a day trying to figure out why I couldn't capture stdout under python, why output wasn't showing up in teamcity, why powershell and cmd prompt were printing different things when running my app.

If there is a way to fix this under electron it would be really helpful to the rest of us.

[mkozakov]

This is still relevant. Please consider addressing

[mattlohkamp]

I understand that the most common case mirrors console.log, but the fact that "process.stdout.write doesn't write to the stdout" is completely unintuitive - I'd be willing to bet that most developers who've tried to capture stdout from electron have run into this poor design choice, have had to run through the same merry-go-round of bug reports and QA-site posts, and have eventually circled back to complain that they're being given the run around.

[Nantris]

This is killing me. I expected if I made a process with only a main and no renderer I'd be able to find a way to get stdio, but no dice on Windows.

[Delwing]

Yet when I try to run portable .exe

set ELECTRON_NO_ATTACH_CONSOLE='true' && "app.exe" > test.txt

it has no effect.

Am I doing something wrong or this doesn't work with portable exe? When running from npm or yarn it does work.

[Nantris]

@Delwing ELECTRON_NO_ATTACH_CONSOLE doesn't resolve the issue of not being able to use stdio on Windows.