This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Bug: Cygwin Shell hangs, waiting, when win32-GVIM forks into background
Brian Dessent wrote:
[ Re: Subject, it seems a little presumptuous to assume that this is a
bug in Cygwin. I don't see anything wrong here. ]
---
Perhaps -- you don't, but my first symptom of a problem was a simple cygwin
program refusing to run from cmd.exe. At the same time, I'm having
problems with 'bash' (or 'ash') as launched from windows as well -- in both
cases, the programs "used to work", and now I see a cmd-window come up,
something flashes by in under a tenth of a second, and the window closes, so I
couldn't see the error in either case. Those were the first two indications
that previously working code had developed problems (I recently downloaded
updated cygwin binaries, including the experimental cygwin.dll. I backed
that out and went to the 'currently released one. It made no difference.
Trying the commands manually in the normal shell worked fine.
Finally with gvim.exe, I was able to get the reproduce it from a cmd.exe
shell launched from windows (entering cmd.exe from bash won't do it).
That was my 2nd indication of a problem -- cygwin's libraries spitting out
multiple failure messages. It certainly is not a POSIX error messages
that I'm aware of.
Then I ran into the gvim help -- and, yes, was mislead by the
apparent "bug" in gvim -- where it does not work as documented.
So I'll go back to my first posted problem. Why can't I fork when
running from cmd.exe if the binary I am running is in "\windows" or
"\windows\system32" I'm not aware of there being special cases for \windows
or \windows\system32 in Posix either. The Cygwin "bin" dir is first in my
path, so cygwin libraries should be accessible via the path.
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.
---
That is a "non-sequitur". Are you saying there is no way for
a process to create another process out of it's own process space and
allow it to continue on "in background", while the first process terminates?
I'm pretty sure the "&" addendum in cmd.exe does something similar to this
within cmd. The functionality seems to be there despite that the function
may not be called "fork" nor have the exact same semantics of "fork".
This is standard behavior of cmd.exe -- if the launched executable is a
GUI app[1] it returns immediately and does not wait.
----
It is not immediately evident where the splitting of the GUI
process off into the background is done: whether in in cmd.exe or
every windows program that can interactively launch processes,
or in the processes themselves. Usually, a "hint" is that if a program
has an option to "-daemonize" or not, is a hint of a dual nature, though I
certainly can't think of any on Windows, where things seem predominantly
limited to CLI or GUI interfaces (seemingly not a "great" design
decision, but it's a bastard schizophrenic OS, so what can one expect.
I see nothing different with gvim
in this case -- you should launch it as "gvim &" if you want the shell
prompt not to wait.
---
It's a typing stressor...not always a bother, but enough so that it isn't
automatic. On Linux, "not a problem", but due to a cygwin incompatibility with
Linux (a design "deficit" (bug)), I can't just
hit Control-Z to put it in background after the fact. I have to
terminate the program (presuming it can be terminated without botching
up some work or losing work) and restart it.
I frequently do not start commands in background, because I
want to make sure they start correctly. On Linux, I can then suspend and
through them in background. Not possible on Cygwin. Hitting the & is
one of my "problem keys"...besides cross-hand coordination, with left
hand in lower left holding shift (and sometimes missing and hitting
control or capslock), the right hand has to stretch up off home-row and
aim for 7, but often hitting 6 or 8 due to the reach taking my hand off
home row. I can't quite do it with 1 hand. Most guys I know can -- larger
hands, and some women are lucky enough to have long fingers (though I'm sure
they suffer when trying to find gloves that fit, that expect shorter fingers
on women with narrower hands or fingers too long when hands are wide enough
*plegh*.
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.
---
Perhaps true, bit I also had a "foolish" expectation that some effort would have
been made to make the application behave the same across multiple platforms,
especially when it is documented to do so.
And regarding that issue, I don't see why
your wrapper needs to fork() at all, it could simply exec() the program
directly. If it did that, it still wouldn't put a graphical program that I
expected to be launched graphically, in background, detached from the terminal.
In fact, I don't see why your wrapper even needs to be a
Cygwin program, it could be a much simpler MinGW wrapper:
---
I agree, but wasn't familiar enough with the Win32 version of
'fork' to write my program that way.
int main (int argc, char **argv) { _execvp ("gvim.exe", argv); }
---
Need to include the path -- that's one of the reasons for
the redirector.
I don't know why you get stack errors with your wrapper. You might need
a rebaseall.
---
As mentioned before, I already did that.
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.
---
Right -- I want the graphical program to launch and return control
to the shell no matter what shell I am in without having to type &. "&" is
embedded in my brain as "launch a long running process in background while
I go do something in foreground. Editing doesn't fit into that paradigm.
I hesitate to even suggest this, but maybe bash and other shells
should have an option to detect non-cygwin GUI programs and launch them
in background? It would give a consistent shell presentation on windows
as well as between linux-and-cygwin. As it stand now, givm launched on
linux launches in background. gvim launched via cmd.exe or the windows
shell launches in background. The only place gvim doesn't launch
automatically into the background is under a cygwin shell.
If cygwin is intended to follow the linux in behavior, I assert,
in this case, it is not and would be more compatible if it new a launched
binary was a Windows-GUI program that would normally be launched in
on windows (or, with its equivalent posix-GUI, on linux).
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 &".
----
It is more effort to try to figure out whether I want the "&"
or not "before" I hit return and physically perform the motions
necessary. If it was easier to simply add a '&', I wouldn't have bothered.
I know that's you believe that I'm not up to the task of having figured
out that I can use "&", but I've been using unix shells with this feature
since 1986, at least, and sporadically before that, so I am vaguely
familiar with the feature. Thank you. But along with "&" are features
like "Control-Z" and there are some programs that automatically default
to launching in background as they expect you don't want your console tied
up and there are systems that support "fork" (or an emulation thereof)
without failing randomly. Being able to adapt a linux/posix environment
is one of its strengths -- being stuck in doing it one way is more
Microsoft's game.
Sorry if my calling the wrong behavior a "bug" irked you. Doesn't
mean that things are working they way they should or that there isn't a
bug. It's fairly common for "interfaces" between programs to be points
of contention as far as which interface is correct...certainly not something
to get overly stress about (normally)... But we all get stressed at times
and though I can't speak for you, most people's stress-dealing behavior
is not usually an example of their best or even their normal
behavior (unless they are stressed ALL the time...:-)).
-l
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/
--
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/