Support job control for Windows programs invoked under Bash (ctrl-c, ctrl-z support)
robgssp opened this issue · 22 comments
It would be good to be able to use Bash job control (suspend/background/etc) in the context of Windows interop. It's currently partially supported under preview builds (can launch windows programs in the background, e.g. notepad.exe &), but once a windows program is started in the foreground you cannot suspend it with ^Z, and interrupting it with ^C transfers control back to bash but doesn't actually kill the Windows program, just detaches it.
I personally find it quite useful to be able to decide I want something backgrounded after I've launched it, and I'd like to be able to do that with e.g. MSBuild invocations.
This is somewhat similar to #1574 although that issue only calls out control-c. Since this one is a bit more generic I'm going to close out the other issue and refer to this one.
For me this begs the question, though, whether it is really a good idea to make Ctrl+Z suspend a Windows process, in particular when it has any windows. It can cause a chain reaction which may hang multiple other applications this way, I think... at least this is what happened to me multiple times before (mostly during debugging sessions, though).
Yes, it may be the fault of other applications to wait infinitely for the responses of windows which don't belong to them, but it can be still very problematic. I remember that when I had this issue while I was using the input macro tool Breevy, I came into a state where almost none of the keys and mouse operations were working anymore until I somehow managed to kill Breevy using a lot of trickery because I couldn't afford restarting the computer at that point...
Please pardon my Windows naivety -- does there already exist a Windows equivalent of SIGSTOP (which I assume is how suspending a process is implemented)? What would the obvious (if any) mapping of this Linux functionality into Windows look like for the Windows application?
(What I'm really asking is, is there a Windows semantic equivalent that's common enough that most programs ought to mostly support it without blowing up too horribly? Suspending just one process in a cloud of Linux processes is problematic too, but usually you don't get yourself too deep into trouble by doing so.)
As far as I know, suspending a process is done just by calling SuspendProcess which suspends all threads. The issue I was trying to point out is that if the process in question wasn't designed for being suspended and has windows which are supposed to pump messages, other applications which naively send a message to such a window (may be even broadcast) and wait for the response can get stuck because of that.
It's probably an edge case when something like my situation described before happens, but I know it can happen.
I do believe though that pure console processes can be suspended and resumed just fine and will work as expected...
Well that can happen on Linux as well if processes are doing any kind of synchronous ipc without timeout. But most normal communication between windows that aren't intimately connected are done with posted messages.
Though the fact that the windows of a suspended process can't be moved may also be somewhat annoying. I guess that usually when a process is suspended on windows it's because of it being debugged or some debug-like scenario like making a memory dump. Note that the only documented way to suspend a complete process, DebugActiveProcessStop, requires you to be debugging the process. The NtSuspendProcess function is undocumented.
For this to work well I think there would actually need to be some sort of support for processes being suspended for non-debugging purpose, which the window manager could use as a hint to show the windows somewhat like they are for non-responding processes, just with an indication that the process is suspended.
@poizan42 If a GUI application's message pump doesn't accept any input for a timeout period (or rather, the application doesn't call GetMessage or DispatchMessage), won't Windows just flag that process as "Not Responding" and ghost all of its active windows (unless the process happened to call DisableProcessWindowGhosting() - pretty unlikely). The user should still be able to move the Windows around, it'll just appear as if the program has crashed (here are some edge cases with active dialogue boxes too, but not a big deal).
@crozone normally yes, but not if it's suspended. Try using e.g. ProcessHacker to suspend a process with a window and see what happens.
Running into this... ctrl+c would be great if it would be passed along!
I use ctrl-c for killing processes a lot more than ctrl-z for suspension, it would be really great to have ctrl-c passed along for interop-launched processes! If suspension is complicated, think that we might see just ctrl-c support come first? :)
@davidhewitt - Thanks for the feedback. This looks like a general request for job control of Win32 processes within bash. I would suggest opening up a user voice ticket for this, if there is not one already, or upvoting an existing one. It helps us prioritize features for future.
Thanks - I opened a ticket at https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/20492437-support-ctrl-c-signals-for-windows-applications-la, as I didn't find an existing one. Thought I'd post it back here incase anyone else looking for this behaviour winds up here.
Will this land in the fall update?
Does anyone have a workaround for killing the windows process from bash? I'm running some windows console apps from bash and I would like a way to kill the process when I need to (to mimic what ctrl-c) should do.
Will anything be done about this ?
Starting Windows programs from WSL is useful but if you cannot stop them with CTRL-C it is really super painful. My specific use case is launching gradle.bat for a build than can take up to 2 min, but I cannot cancel it. Why not use Linux gradle you ask ? Because gradle.bat uses Windows Java which is faster, especially for I/O. The workaround is to use a cmd.exe console but I wish I could use WSL (wsltty in my case) for all my console needs...
It seems that this works in general, but fails for the very first Windows process started per WSL session. I have opened a separate issue for this: #3760
A workaround can be running a Windows process which does nothing from your .bashrc. Just add a line rundll32.exe (which will do nothing if launched without arguments) to the bottom of ~/.bashrc. This way, the first process you manually run in a bash session will always actually be the second process, hence it won't misbehave.
After upgrading to 1903, this feature has stopped working entirely (previously was working in 1809 as described by @CherryDT).
I have been able to fix / workaround this issue with the following script: https://gist.github.com/davidbailey00/004da18b89fff0534edd9b6f6082bcaf
By installing this script, you can launch a Windows process and kill it from Linux, using either CTRL+C or by sending a SIGTERM signal. If the process exits by itself, the script will also exit.
Also for me this feature is not working at all. I'm starting a windows-java process from WSL (the java process needs some windows specific things, so I can't use a wsl internal java). It starts fine and works. But I can not stop it. Currently killing it from task manager, but thats realy a tiem consuming workaround.
I did a full reset of my WSL installation as it started to behave realy strange overall. I can now CTRL+C out of a running java process. So this works now:
/mnt/c/Program\ Files/Java/jdk1.8.0_161/bin/java.exe -jar ./springBootServer.jar
-> will print logs
-> CTRL+C closes it
But this is not working, not an issue for me, but I think that is the issue addressed here:
cmd.exe /c notepad
-> will start notepad
-> CTRL+C will not close it
This seems to still be a bit broken. I see this when using alias git=git.exe to avoid different git clients and wanting different indices. It would be great to background git log but when it's paging (presumably with the less.exe that comes with Git for Windows) it just bells at me when I Ctrl-C or Ctrl-Z.
Some silly experiment I did was to git --no-pager log --stat on a medium size repo, and Ctrl-C could not kill that either (nor could Ctrl-Z background it). Another interesting one was running /mnt/c/Windows/System32/notepad.exe and both Ctrl-C and Ctrl-Z "do something" but nothing that affects the GUI window created.
This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.
Thank you!