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

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

Expand Messages
  • Fabian Greffrath
    ... You are perfectly right! I have copied MSYS s vim.exe (and the dynamic libs it depends on) into a separate directory. In a cmd.exe shell, I chdir into this
    Message 1 of 20 , Jun 6, 2011
    • 0 Attachment
      Am 02.06.2011 17:07, schrieb Bram Moolenaar:
      > It's perfectly OK for homedir to be NULL. Setting it to any random
      > directory is not a good idea.

      You are perfectly right!

      I have copied MSYS's vim.exe (and the dynamic libs it depends on) into
      a separate directory. In a cmd.exe shell, I chdir into this directory
      and "set HOME=" and "set PATH=". If I then start vim, it complains
      twice that it "Cannot execute shell sh" and that it "Cannot expand
      wildcards" and forces me to "Press ENTER" but then continues without
      further complaints.

      If I leave both environment variables unset and I now copy MSYS's
      sh.exe (i.e. a hard link to bash.exe) into this directory, vim.exe
      crashes at start.

      If I set HOME back to something reasonable, vim.exe starts
      successfully and merely complains that it cannot find its syntax.vim
      file (I have "syntax on" in my $HOME/.vimrc).

      > Where does Vim crash when homedir is NULL? That should be fixed.

      However, since vim starts without crashing when HOME is unset and
      sh.exe is *absent*, I think it's not an issue in vim.exe itself, but
      maybe in the way it invokes the shell. The sh.exe I just copied over
      from MSYS starts just fine even if HOME is unset...

      - 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
    • Fabian Greffrath
      ... With both PATH and HOME unset, the shell seems to choke on the following command: call_shell (unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo
      Message 2 of 20 , Jun 6, 2011
      • 0 Attachment
        Am 06.06.2011 14:22, schrieb Fabian Greffrath:
        > However, since vim starts without crashing when HOME is unset and
        > sh.exe is *absent*, I think it's not an issue in vim.exe itself, but
        > maybe in the way it invokes the shell. The sh.exe I just copied over
        > from MSYS starts just fine even if HOME is unset...

        With both PATH and HOME unset, the shell seems to choke on the
        following command:

        call_shell (unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo
        "$1"; shift; done }; vimglob >/tmp/v368869/0 ~/.vim/plugin/**/*.vim, 18)

        which it is given in os_unix.c:5597.

        - 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
      • Bram Moolenaar
        ... This tries to expand a file pattern starting with ~/ , which won t work when $HOME isn t set. However, it should not crash. You say the shell chokes on
        Message 3 of 20 , Jun 6, 2011
        • 0 Attachment
          Fabian Greffrath wrote:

          > Am 06.06.2011 14:22, schrieb Fabian Greffrath:
          > > However, since vim starts without crashing when HOME is unset and
          > > sh.exe is *absent*, I think it's not an issue in vim.exe itself, but
          > > maybe in the way it invokes the shell. The sh.exe I just copied over
          > > from MSYS starts just fine even if HOME is unset...
          >
          > With both PATH and HOME unset, the shell seems to choke on the
          > following command:
          >
          > call_shell (unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo
          > "$1"; shift; done }; vimglob >/tmp/v368869/0 ~/.vim/plugin/**/*.vim, 18)
          >
          > which it is given in os_unix.c:5597.

          This tries to expand a file pattern starting with "~/", which won't work
          when $HOME isn't set. However, it should not crash.

          You say the shell chokes on the command, but how does that make Vim
          crash?

          --
          Drink wet cement and get really stoned.

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ an exciting new programming language -- http://www.Zimbu.org ///
          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

          --
          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
        • Fabian Greffrath
          ... I don t know. Maybe it s just Windows that for some reason *believes* that vim has crashed [1]. However, I have just tried out with another shell, i.e. the
          Message 4 of 20 , Jun 6, 2011
          • 0 Attachment
            Am 07.06.2011 05:40, schrieb Bram Moolenaar:
            > This tries to expand a file pattern starting with "~/", which won't work
            > when $HOME isn't set. However, it should not crash.
            >
            > You say the shell chokes on the command, but how does that make Vim
            > crash?

            I don't know. Maybe it's just Windows that for some reason *believes*
            that vim has crashed [1]. However, I have just tried out with another
            shell, i.e. the sh.exe from UnxUtils (which is a zsh) and it works
            even if both PATH and HOME are unset!

            - Fabian


            [1] These are the debug messages that Windows presents to me (in
            German, sorry):

            Problemsignatur:
            Problemereignisname: APPCRASH
            Anwendungsname: conhost.exe
            Anwendungsversion: 6.1.7601.17514
            Anwendungszeitstempel: 4ce79a18
            Fehlermodulname: conhost.exe
            Fehlermodulversion: 6.1.7601.17514
            Fehlermodulzeitstempel: 4ce79a18
            Ausnahmecode: c0000005
            Ausnahmeoffset: 0000000000001e65
            Betriebsystemversion: 6.1.7601.2.1.0.256.4
            Gebietsschema-ID: 1031
            Zusatzinformation 1: f7b2
            Zusatzinformation 2: f7b24610852830221d2f973252451319
            Zusatzinformation 3: 1131
            Zusatzinformation 4: 11317911aee4606a99ac6986df83c9f2

            Lesen Sie unsere Datenschutzbestimmungen online:
            http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407

            Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie
            unsere Datenschutzbestimmungen offline:
            C:\Windows\system32\de-DE\erofflps.txt

            --
            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
          • Bram Moolenaar
            ... I guess what happens is that the shell dies, and takes Vim with it. I don t think it is up to Vim to set $HOME just to avoid the shell from dying. You
            Message 5 of 20 , Jun 7, 2011
            • 0 Attachment
              fabian greffrath wrote:

              > Am 07.06.2011 05:40, schrieb Bram Moolenaar:
              > > This tries to expand a file pattern starting with "~/", which won't work
              > > when $HOME isn't set. However, it should not crash.
              > >
              > > You say the shell chokes on the command, but how does that make Vim
              > > crash?
              >
              > I don't know. Maybe it's just Windows that for some reason *believes*
              > that vim has crashed [1]. However, I have just tried out with another
              > shell, i.e. the sh.exe from UnxUtils (which is a zsh) and it works
              > even if both PATH and HOME are unset!
              >
              > - Fabian
              >
              >
              > [1] These are the debug messages that Windows presents to me (in
              > German, sorry):
              >
              > Problemsignatur:
              > Problemereignisname: APPCRASH
              > Anwendungsname: conhost.exe
              > Anwendungsversion: 6.1.7601.17514
              > Anwendungszeitstempel: 4ce79a18
              > Fehlermodulname: conhost.exe
              > Fehlermodulversion: 6.1.7601.17514
              > Fehlermodulzeitstempel: 4ce79a18
              > Ausnahmecode: c0000005
              > Ausnahmeoffset: 0000000000001e65
              > Betriebsystemversion: 6.1.7601.2.1.0.256.4
              > Gebietsschema-ID: 1031
              > Zusatzinformation 1: f7b2
              > Zusatzinformation 2: f7b24610852830221d2f973252451319
              > Zusatzinformation 3: 1131
              > Zusatzinformation 4: 11317911aee4606a99ac6986df83c9f2
              >
              > Lesen Sie unsere Datenschutzbestimmungen online:
              > http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407
              >
              > Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie
              > unsere Datenschutzbestimmungen offline:
              > C:\Windows\system32\de-DE\erofflps.txt

              I guess what happens is that the shell dies, and takes Vim with it.
              I don't think it is up to Vim to set $HOME just to avoid the shell from
              dying.

              You could try running that conhost.exe without $HOME in another context,
              see what happens.

              --
              hundred-and-one symptoms of being an internet addict:
              152. You find yourself falling for someone you've never seen or hardly
              know, but, boy can he/she TYPE!!!!!!

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ an exciting new programming language -- http://www.Zimbu.org ///
              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

              --
              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
            • Ben Schmidt
              ... Can it be reproduced without Vim? If so, a bug can be filed against the shell. If not, perhaps we haven t fully understood it yet? Ben. -- You received
              Message 6 of 20 , Jun 7, 2011
              • 0 Attachment
                On 8/06/11 2:38 PM, Bram Moolenaar wrote:
                >
                > fabian greffrath wrote:
                >
                >> Am 07.06.2011 05:40, schrieb Bram Moolenaar:
                >>> This tries to expand a file pattern starting with "~/", which won't work
                >>> when $HOME isn't set. However, it should not crash.
                >>>
                >>> You say the shell chokes on the command, but how does that make Vim
                >>> crash?
                >>
                >> I don't know. Maybe it's just Windows that for some reason *believes*
                >> that vim has crashed [1]. However, I have just tried out with another
                >> shell, i.e. the sh.exe from UnxUtils (which is a zsh) and it works
                >> even if both PATH and HOME are unset!
                >>
                >> - Fabian
                >>
                >>
                >> [1] These are the debug messages that Windows presents to me (in
                >> German, sorry):
                >>
                >> Problemsignatur:
                >> Problemereignisname: APPCRASH
                >> Anwendungsname: conhost.exe
                >> Anwendungsversion: 6.1.7601.17514
                >> Anwendungszeitstempel: 4ce79a18
                >> Fehlermodulname: conhost.exe
                >> Fehlermodulversion: 6.1.7601.17514
                >> Fehlermodulzeitstempel: 4ce79a18
                >> Ausnahmecode: c0000005
                >> Ausnahmeoffset: 0000000000001e65
                >> Betriebsystemversion: 6.1.7601.2.1.0.256.4
                >> Gebietsschema-ID: 1031
                >> Zusatzinformation 1: f7b2
                >> Zusatzinformation 2: f7b24610852830221d2f973252451319
                >> Zusatzinformation 3: 1131
                >> Zusatzinformation 4: 11317911aee4606a99ac6986df83c9f2
                >>
                >> Lesen Sie unsere Datenschutzbestimmungen online:
                >> http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407
                >>
                >> Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie
                >> unsere Datenschutzbestimmungen offline:
                >> C:\Windows\system32\de-DE\erofflps.txt
                >
                > I guess what happens is that the shell dies, and takes Vim with it.
                > I don't think it is up to Vim to set $HOME just to avoid the shell from
                > dying.
                >
                > You could try running that conhost.exe without $HOME in another context,
                > see what happens.

                Can it be reproduced without Vim? If so, a bug can be filed against the
                shell. If not, perhaps we haven't fully understood it yet?

                Ben.



                --
                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
              • Fabian Greffrath
                ... No, I have not yet succeeded to reproduce this behaviour outside vim. If I run ... $1 ; shift; done }; vimglob /tmp/v368869/0 ~/.vim/plugin/**/*.vim
                Message 7 of 20 , Jun 8, 2011
                • 0 Attachment
                  Am 08.06.2011 07:13, schrieb Ben Schmidt:
                  > Can it be reproduced without Vim? If so, a bug can be filed against the
                  > shell. If not, perhaps we haven't fully understood it yet?

                  No, I have not yet succeeded to reproduce this behaviour outside vim.

                  If I run

                  > set HOME=
                  > sh -c "unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo
                  "$1"; shift; done }; vimglob >/tmp/v368869/0 ~/.vim/plugin/**/*.vim"

                  from the command prompt, the shell exits normally.

                  --
                  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
                • Ernie Rael
                  ... I haven t been following this thread closely, but just to point out ... and ... do two different things -ernie -- You received this message from the
                  Message 8 of 20 , Jun 8, 2011
                  • 0 Attachment
                    On 6/8/2011 12:33 AM, Fabian Greffrath wrote:
                    >
                    > No, I have not yet succeeded to reproduce this behaviour outside vim.
                    >
                    > If I run
                    >
                    > > set HOME=
                    > > sh -c "unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo
                    > "$1"; shift; done }; vimglob >/tmp/v368869/0 ~/.vim/plugin/**/*.vim"
                    >
                    > from the command prompt, the shell exits normally.
                    >
                    I haven't been following this thread closely, but just to point out
                    > set HOME=
                    and
                    > unset HOME
                    do two different things

                    -ernie

                    --
                    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
                  • Fabian Greffrath
                    Hi Earnie, ... we are on a cmd.exe prompt, where there is no such thing as unset there. ;) - Fabian -- You received this message from the vim_dev maillist.
                    Message 9 of 20 , Jun 8, 2011
                    • 0 Attachment
                      Hi Earnie,

                      Am 08.06.2011 15:30, schrieb Ernie Rael:
                      > I haven't been following this thread closely, but just to point out
                      > > set HOME=
                      > and
                      > > unset HOME
                      > do two different things

                      we are on a cmd.exe prompt, where there is no such thing as "unset"
                      there. ;)

                      - 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
                    • Fabian Greffrath
                      Hi all, ... 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
                      Message 10 of 20 , Oct 21, 2011
                      • 0 Attachment
                        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

                        --
                        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
                      • Fabian Greffrath
                        [Sent twice, sorry. First mail went to . Which is the right address for the vim-dev list, actually?] Hi all, ... I have investigated
                        Message 11 of 20 , Oct 21, 2011
                        • 0 Attachment
                          [Sent twice, sorry. First mail went to <vim_dev@...>.
                          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
                        • Tony Mechelynck
                          ... 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
                          Message 12 of 20 , Oct 21, 2011
                          • 0 Attachment
                            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
                          • Bram Moolenaar
                            ... Hmm, keep in mind you are using code written for Unix on MS-Windows. That s never going to work perfectly. Perhaps a few #ifdefs will make the code work
                            Message 13 of 20 , Oct 22, 2011
                            • 0 Attachment
                              Fabian Greffrath wrote:

                              > 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?

                              Hmm, keep in mind you are using code written for Unix on MS-Windows.
                              That's never going to work perfectly.

                              Perhaps a few #ifdefs will make the code work for MS-Windows. I do hope
                              we can keep that to a minimum though, otherwise it gets messy.

                              --
                              From "know your smileys":
                              2B|^2B Message from Shakespeare

                              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                              \\\ an exciting new programming language -- http://www.Zimbu.org ///
                              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                              --
                              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
                            • Fabian Greffrath
                              Dear Tony, ... thank you very much for your insightful answer! However, there are two more things that I don t understand in the face of your reply. 1) The
                              Message 14 of 20 , Oct 24, 2011
                              • 0 Attachment
                                Dear Tony,

                                Am 21.10.2011 16:15, schrieb Tony Mechelynck:
                                > 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.

                                thank you very much for your insightful answer!

                                However, there are two more things that I don't understand in the face
                                of your reply.

                                1) The following code exits peacefully (with $?==0) if compiled under
                                either MinGW or MSYS, how can that be?

                                #include <stdio.h>

                                int main (void)
                                {
                                fclose(stdin);
                                fclose(stdout);
                                fclose(stderr);
                                return 0;
                                }

                                2) Vim starts fine if the sh.exe found in PATH is a copy of zsh.exe
                                from UnxUtils (but vim complains about "E79: Cannot expand wildcards"
                                then), but it chrashes if it's bash.exe from MSYS, why?

                                Well, the code discussed here is in the child process of a fork()
                                executed earlier. Maybe the culprit is in the parent process, but I
                                haven't seen it so far...

                                - 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
                              • Fabian Greffrath
                                ... #ifdefs won t help, as the code is built in an UNIX-like environment (i.e. MSYS) but run in a cmd.exe window, so this has to get detected at runtime. --
                                Message 15 of 20 , Oct 24, 2011
                                • 0 Attachment
                                  Am 22.10.2011 18:04, schrieb Bram Moolenaar:
                                  > Perhaps a few #ifdefs will make the code work for MS-Windows. I do hope
                                  > we can keep that to a minimum though, otherwise it gets messy.

                                  #ifdefs won't help, as the code is built in an UNIX-like environment
                                  (i.e. MSYS) but run in a cmd.exe window, so this has to get detected
                                  at runtime.

                                  --
                                  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
                                • Fabian Greffrath
                                  ... And today I think I can give answer to both of my questions myself. It turns out to be a bit tricky to debug code by means of printf()s when you have just
                                  Message 16 of 20 , Oct 25, 2011
                                  • 0 Attachment
                                    Am 24.10.2011 10:51, schrieb Fabian Greffrath:
                                    > However, there are two more things that I don't understand in the face
                                    > of your reply.

                                    And today I think I can give answer to both of my questions myself. It
                                    turns out to be a bit tricky to debug code by means of printf()s when
                                    you have just closed all your standard file decriptors. ;) And when I
                                    keep one of them open to print debug messages, the bug does not occur
                                    anymore. I think this is called a Heisenbug. ;)

                                    Well, I have helped myself by open()ing files which have line numbers
                                    as their file names and it turns out that sh.exe is indeed the
                                    culprit. It hangs and does not return from the execvp() around line
                                    4130 in os_unix.c, which is in the child process after fork() has been
                                    invoked. As a consequence the waitpid() in the parent process hangs,
                                    too, and Windows decides to terminate the process. So or similar.

                                    Trying to find out today what makes the shell hang...

                                    - 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
                                  Your message has been successfully submitted and would be delivered to recipients shortly.