Support terminal use on Windows to be optional with a new value `attach` for the new `--console=` option. about nuitka HOT 9 CLOSED

This is now on the develop branch.

from nuitka.

The AttachConsole use is a major finding, and we need to use that in the C code of Nuitka. I am very happy about that, as it means GUI programs will be able to properly be debugged without forcing the output elsewhere. This applies to standalone and onefile, their interaction might make it a bit more difficult, but I believe onefile might always be running when the Python program checks its parent, if there is an issue with that, it would be bad. With no cleanup needed, onefile might quit too soon, that would have to be looked at.

The second point, I don't get what flag you are talking about and why it would be needed.

from nuitka.

I want to make this work for standalone too, and not just onefile, where there is of course the extra step to launch a new process, such that the Python DLL never sees it, occurs. I was not immediately successful with it though.

from nuitka.

So, I made this to work, the change has interesting effects in case of an assertion, etc. this now raises GUI dialogs potentially, which is not a bad thing though, since they offer to debug inside of Visual Studio, which can make things a bit easier at times maybe.

The code attaches to the console, and re-opens CONOUT$ and CONIN$ for stdout/stderr/stdin if they were not re-directed, I need however to check if the later works beyond stdout right now. For the command line interface this will mean big changes, with --console=force|attach|disable where old --enable-console is force and disable is something I actually need to implement still, and the new default is attach which uses console if available.

from nuitka.

So, implement the --disable-console (--console=disable) and --enable-console (--console=force) as to just not attach to the console, and forcing it simply doesn't use the subsystem on Windows, that is enough to deal with it. That should make it perfect.

Not sure yet, how this relates to onefile. Currently accelerated and standalone are working nicely. I guess, the onefile should maybe always attach itself, so it can forward it, I shall try it out.

from nuitka.

So, I found that os.system and subprocess in general work very badly in this context. I noticed no outputs are given, and it seems the file handles that Nuitka creates are invalid for CONIN$ and CONOUT$ for most anything.

When I noticed that the subprocess call didn't output anything, I removed the check to see if all of stdin, stdout, and stderr are None, which they were. I noticed that if one of them is given, the subprocess will crash because it is unable to, e.g., duplicate stdin.

When I looked at os.system, I saw that it calls a function _wsystem and not much else, so Win32 is not finding the standard handles as something it wants to pass. In the onefile bootstrap, I noticed that I had to make the handles inherited by the child process to pass on the attached console handles.

So I am either missing something fundamental or this might well be very unusable. I can, of course, patch up subprocess somehow to use pipes that throw away or get output delayed, but it seems this might not be generally doable. I am struggling to find out what outside of attaching is necessary to make the console handles inherited more automatically, which probably makes them possible to duplicate.

It's looking grim though.

from nuitka.

I figured it out, cannot use _wrefopen but instead the standard handles are now created with CreateFile and as inheritable, and then subprocess and os.system don't care anymore and just work fine.

I think there is issues with stderr being buffered right now, but I hope to find fixes for that too.

from nuitka.

Ok, made it non-default again. Turns out, that if not started correctly, i.e. from a shell, the redirections are lost and do not apply, so that output goes to the attached terminal no matter what you do. That's fine for programs that typically run without it, but means it is not really suitable for anything else. I confused myself by looking at accelerated mode, which runs through CMD.exe, which kind of starts it different than e.g. subprocess.call of any Python will. This is about the create flag that was pointed out.

Anyway, it's better than nothing surely.

from nuitka.

Part of the 2.3 release.

from nuitka.