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

Linda Walsh cygwin@tlinx.org
Mon Mar 10 03:16:00 GMT 2008


I'm not certain this bug has the same root cause as the fork problem I
reported earlier, but it has some odd 'coincidences' if it isn't
related.   Something may be broken in the fork code that is affecting both 
problems and my bash.exe problem I haven't explored yet.  But starting
with the "simplest".

For my GUI-VIM, I use the "Windows" version.

from "ftp://ftp.vim.org/pub/vim/pc/gvim71.exe".

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"

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).

When running in a cygwin shell (ash, bash, tcsh tried), also in
the vimdir, typing in "/prog/vim/gvim" starts gvim but hangs the
shell that launched it until gvim is exited (or one can manually
terminate the shell window).

I ran into this problem trying to get around the system-dir specific
fork bug that comes out of cygwin that I reported earlier.
In investigating that, I "re-remembered", that I shouldn't
need to do my own "fork" in my "gvim redirector" -- I just needed to
make sure the real "gvim" was launched from the correct location since
it already launches (or, does under Windows) in background and the
launching program exits (and returns to explorer or 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).

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.

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.

-linda
(cygcheck.out attached)



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cygcheck.out
URL: <http://cygwin.com/pipermail/cygwin/attachments/20080310/ed087317/attachment.ksh>
-------------- next part --------------
--
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/


More information about the Cygwin mailing list