This is the mail archive of the
mailing list for the Cygwin project.
Re: Ctrl-Z fails to suspend Windows programs
Thorsten Kampe <email@example.com> writes:
> Why should Cygwin zsh have such a feature and make a difference
> between a GUI and a non GUI application?
1) Most native Windows apps don't read from or write to the invoking shell window
- it doesn't add much value to run them in the "foreground".
2) Once started (in the foreground) it's not possible to suspend such a
> When you invoke a non GUI application, you won't return to the prompt unless
> the application has finished. Same with zsh under Linux. If you start a GUI
> without a "&" you don't get a prompt.
Yes, but the key difference is that on Linux you can always get back to the
shell window by suspending the GUI app with ^Z (or whatever is your susp char).
> And you still can [Ctrl]+[C] the GUI app which you couldn't when it was run
> in the background.
The problem is that I often don't want to have to terminate the GUI app just to
get my shell prompt back.
> * Peter A. Castro (2004-06-17 22:13 +0100)
> > On Tue, 15 Jun 2004, John Cooper wrote:
> >> > The point is that it's not about cygwin-vs-windoze apps. It's about
> >> > apps-that-use-console-stdin-and-stdout vs. apps-that-display-a-gui; those
> >> > that show a gui could usefully be detached, but those that read their input
> >> > from stdin will break if the shell detaches them.
> > Hi John,
> > I'm the maintainer for zsh on Cygwin.
> >> Yes, you're right, the old "native" zsh option was specifically to do with GUI
> >> apps rather than "Windows" apps per se - here's the doc to for enabling the
> >> option (it was off by default):
> >> winntwaitforguiapps: When set, makes the shell wait for win32 GUI apps to
> >> terminate instead of spawning them asynchronously.
> >> > I don't think there's a reliable enough mechanism by which a shell could
> >> > detect one case from the other.
> >> Below is the code it used to determine if a program is a GUI program or not. I
> >> don't know how well it works under all conditions; however it did work fine for
> >> me.
> >> Even if not perfectly reliable, could something like this be added but disabled
> >> by default? I for one would find it useful.
> > I guess I don't really have much of a problem with adding such a feature,
> > provided it's something that many users really want. I can see some
> > merit to it, but is it really that much work to type '&' after the
> > command to run it in the background?
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html