[Sent twice, sorry. First mail went to <[email protected]>. Which is the right address for the vim-dev list, actually?]
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 different code path depending on whether a HOME variable is set and whether it succeeds to call a shell (i.e. sh is found in PATH) or not. This led me to believe that the missing HOME variable is the culprit, but it isn't.
Remember, my problem was that vim.exe when 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 (it works with zsh-nt, though, 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
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 -- 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
