Usage on Windows causes shell prompt issues
Silic0nS0ldier opened this issue · comments
Bug description
Invocations of wrapper output on Windows don't play well with the shell prompt. It appears at least once for the initial process creation (startpe 0.0.0 ...
), appears multiple times when batch scripts are used (may be just how batch scripts work, I know little about them), and the prompt for the next command is missing but has stdin appear at the correct indent level.
Reproduction steps
Run generated wrapper on Windows via PowerShell, Cmd, etc.
Note the odd prompt presence.
Additional context
Nope
On Windows this is a bit tricky. Windows programs are either console subsystem programs, which will work properly in a console but always create a console window on start when started from the explorer, or windows subsystem programs, in which they don't create one either way. See here for more details. Currently the Windows runners are all compiled for the windows subsystem and either manually attach to a console when available, or create a new one when packed with the show-console
argument.
AttachConsole
with windows subsystem programs doesn't work as one might hope; As the child program is detached, while its outputs are redirected to the parent console the parent console acts like the child isn't running. So I assume this issue is caused by outputs of the child program intermingling with the parent console.
One option to work around this would be compiling an additional runner for the console subsystem as a choice next to the windows subsystem one. This still leaves the issue with .wait()
/stdin
though.
Actually it seems like .wait()
doesn't preclude the child process from accessing stdin, just the parent process from accessing it. So a console-subsystem runner would solve this.
I'm currently working on a PE file resource editor to include in wrappe, which would allow just setting a flag in the windows header while packing without needing two separate runners. Until then I'm alright with switching the Windows runner to the console subsystem and accept a console window flashing up when starting a GUI application.
The runner in the latest snapshot now wait
s on the spawned child process. Could you check if that solves the problem for you? It should also solve the issue on the other platforms 😄
Working MUCH better now, prompt is showing up only where it would be expected.
One thing I will note. .wait()
will terminate stdin
(to avoid deadlocks in normal usage). This can be avoided by taking ownership of the stdin
handle before calling .wait()
.