On 21/10/11 13:47, Fabian Greffrath wrote:
Hi all,
Am 02.06.2011 17:07, schrieb Bram Moolenaar:
Where does Vim crash when homedir is NULL? That should be fixed.
I have investigated this crash a bit further and tailored it down to a
completely unrelated issue. It is just that vim takes a completely
different code path depending on whether a HOME directory is set and
whether it succeeds to call a shell or not (i.e. sh is in PATH). this is
why I first suspected the missing HOME variable to be the culprit, but
it isn't.
Remember, I had the problem that vim compiled in an MSYS environment
crashes when started from a cmd.exe shell when both (a) HOME is not set
(which is quite common in a cmd.exe shell) and (b) sh.exe is found in
PATH (i.e. it works with zsh-nt but not with MSYS's bash).
I can perfectly start vim under the aforementioned conditions if I
comment out the line calling "fclose(stderr);" in src/os_unix.c around
line 3994, that's function mch_call_shell() with (!pipe_error) && (pid
== 0). The code block which contains the malicious line is introduced
with the following paragraph:
* Don't want to show any message from the shell. Can't just
* close stdout and stderr though, because some systems will
* break if you try to write to them after that, so we must
* use dup() to replace them with something else -- webb
* Connect stdin to /dev/null too, so ":n `cat`" doesn't hang,
* waiting for input.
And this is exactly what happens, both stdout and stderr are closed and
the system breaks afterwards. The following calls to dup() aren't even
reached. How can I circumvent this breakage? It seems that cmd.exe needs
to have at least one file decriptor open?
- Fabian
Dos-style shells (COMMAND.COM, NDOS.COM, 4DOS.COM, cmd.exe, 4NT.EXE,
etc.) open three handles (sysin, sysout and syserr) before starting a
program, and they expect those same three handles still to be open when
the program exits. They don't have to point to three different files or
devices: in the most usual case, all three point to the CON device i.e.
the console keyboard-and-screen device. This is when starting a
"console" application — IIUC, a GUI application is started with no
stdout or stderr unless a >> > or | redirection was explicitly specified
on the command-line (I'm not sure about stdin) and its I/O is handled
differently. For instance it is a known fact that in Windows cmd.exe
"firefox -help" (without the quotes) displays nothing but "firefox -help
|more" (still without the quotes) displays the desired help.
In general, IIRC it takes a lot of precautions to get programs compiled
for a Cygwin environment to behave when run outside the Cygwin shell, or
conversely to get programs compiled for native Windows to behave when
called from the Cygwin shell (I don't know about MSYS). It is possible
in not too extreme cases (and Make_cyg.mak does it when preprocessing
if_perl.xs to auto/if_perl.c) but it requires, among others, constant
attention to /-style and \-style paths and their careful conversion by
means of the cygpath utility.
I recommend invoking "native-Windows" programs (including the Vim
executables compiled with Make_cyg.mak or Make_ming.mak) directly from
cmd.exe or from a desktop shortcut, and invoking "Cygwin" programs
(including Vim versions compiled under Cygwin with the top-level
Makefile and the traditional-Unix "[make config;] make; make install"
procedure) from a Cygwin bash (or sh etc.) prompt. The "Cygwin" icon
placed on your desktop when you install Cygwin converts (before starting
bash, or maybe as the first step before bash displays its prompt) your
Dos-like %HOME% and %PATH% variables to $HOME and $PATH values that
Unix-like programs running under Cygwin will understand (but it doesn't
do the same for every environment variable).
Best regards,
Tony.
--
Somebody ought to cross ball point pens with coat hangers so that the
pens will multiply instead of disappear.
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
