Re: Bug: Cygwin Shell hangs, waiting, when win32-GVIM forks into background

[Brian Dessent <brian at dessent dot net>]

[ Re: Subject, it seems a little presumptuous to assume that this is a
bug in Cygwin.  I don't see anything wrong here. ]

Linda Walsh wrote:

> A working feature in gvim is that it immediately "daemonizes" and goes
> into background wherever it is invoked from (or at least it is
> SUPPOSE to).  If you type "gvim -h" (you'll get a short popup help
> in a window.  Under linux vim 7.1, if you type "vim -h", you get a similar
> help, but sent to the tty instead.  The line of interest is:
> 
> "   -f  or  --nofork     Foreground: Don't fork when starting GUI"

Just because the Win32 version prints that in its help doesn't mean it
does anything.  It's certainly not forking, since it's a native Win32
program.  grep the source for MAY_FORK, and you will see that
gui.c:gui_start() only tries to do this if MAY_FORK is defined, and
MAY_FORK only gets defined if UNIX is defined.  This seems to be
confirmed by the fact that typing both "gvim" and "gvim -f" from a
cmd.exe prompt results in identical behavior -- immediate return.

> Normally, if you invoke the gui version, it automatically goes into
> background.  The same text is there for the Win32 native version.
> 
> If I start GVIM (using specific path), "C:\Prog\Vim\Gvim.exe", in
> cmd.exe, the command prompt immediately returns and the GUI comes up.
> (my "curdir" was also set to the same directory).

This is standard behavior of cmd.exe -- if the launched executable is a
GUI app[1] it returns immediately and does not wait.   You can see the
same behavior with notepad.exe, which certainly has no special "fork and
go in background" code in it.  Other shells have no such special casing:
if you launch notepad from bash, it waits for notepad to terminate
before returning to the shell prompt.  If you don't want to wait you
have to run "notepad &" explicitly.  I see nothing different with gvim
in this case -- you should launch it as "gvim &" if you want the shell
prompt not to wait.  As far as I can see the Win32 gvim is acting
exactly as notepad, i.e. it is doing nothing special to put itself in
the background.  You are attributing something to gvim which is simply a
property of cmd.exe.

> So wazzup with "fork", or more specifically -- what about cygwin
> is preventing proper functioning of a program attempting to go
> into background?  I understand the need to keep around cygwin
> for cygwin-shell programs.  But Win32-GVIM is neither (not cygwin
> nor a shell program).

I don't think this "fork" problem (which really has nothing to do with
forking and everything to do with cmd.exe adding an implicit "&" at the
end of commands that reference GUI binaries) has anything to do with
your other "fork" problem.  And regarding that issue, I don't see why
your wrapper needs to fork() at all, it could simply exec() the program
directly.  In fact, I don't see why your wrapper even needs to be a
Cygwin program, it could be a much simpler MinGW wrapper:

int main (int argc, char **argv) { _execvp ("gvim.exe", argv); }

> Is it possibly related to the fork-bug that gets spit out by the
> cygwin libraries? The interesting "coincidence" there, is that if I
> run my "redirector" prog "natively" under "cmd.exe", that is when my
> "cygwin-based" redirector fails (stack errors).  But for the Win32 GVIM,
> it is running from cmd.exe that results in correct behavior.

I don't know why you get stack errors with your wrapper.  You might need
a rebaseall.  But as above, I see no reason to involve all the
complicated machinery of emulating fork and exec if you simply want a
wrapper that spawns another process and exits.  That is how process
creation on Windows is designed to normally work, so there's no need for
any emulation.

> If I run from a shell, the Win32GVIM doesn't properly go into background,
> but my "redirector" "works" -- no fork errors, and *IT* is able to
> launch the WIN32-Gvim in a "forked" process and then the "redirector"
> CAN exit.  Did I write that clearly enough?  Cause the symptoms sure
> seem strange.

The redirector works simply because the shell is waiting on the process
it created to terminate, which it does.  You could save a lot of effort
by simply telling the shell not to wait, i.e. "gvim &".

Brian

[1] Where GUI app means the PE header 'subsystem' is set to 'windows'
instead of 'console'.  In GNU terms this means it was linked with
-mwindows which is a shortcut for -Wl,--subsystem,windows as opposed to
the default -mconsole aka -Wl,--subsystem,console.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/