Loading ...
Sorry, an error occurred while loading the content.

62907Re: HOME variable in cmd.exe for vim compiled in an UNIX-like environment

Expand Messages
  • Tony Mechelynck
    Oct 21, 2011
      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,
      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
    • Show all 20 messages in this topic