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
    ... Plain vim.exe from MSYS executed in a cmd.exe shell. I have seen something similar to your observations: If I unset HOME in cmd.exe (via set HOME= ) and
    Message 1 of 20 , Jun 1, 2011
      Am 31.05.2011 11:16, schrieb Gary Johnson:
      > Under what conditions does yours crash?

      Plain vim.exe from MSYS executed in a cmd.exe shell.

      I have seen something similar to your observations: If I unset HOME in
      cmd.exe (via "set HOME=") and then run vim.exe from MSYS, it crashes.
      If I first run bash and then start vim.exe from bash, it works, even
      if bash also has its HOME variable unset. Strange...

      However, currently the init_homedir function in misc1.c does not
      consider the case when both UNIX is defined at build time (#ifdef
      UNIX) but (var == NULL) at run time, which is perfectly possible when
      vim is compiled in an MSYS environment (which has __unix defined) but
      executed from a cmd.exe shell without a HOME variable.

      The attached short patch is very pragmatic but at least provides a
      fallback solution when the aforementioned case occures, else the
      init_homedir function may return and the homedir variable is still NULL.


      Cheers,
      - Fabian

      --

      --- misc1.c.orig
      +++ misc1.c
      @@ -3540,6 +3540,8 @@
      }
      #endif
      homedir = vim_strsave(var);
      + } else {
      + homedir = vim_strsave(".");
      }
      }

      --
      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
      ... It s perfectly OK for homedir to be NULL. Setting it to any random directory is not a good idea. Where does Vim crash when homedir is NULL? That should
      Message 2 of 20 , Jun 2, 2011
        Fabian Greffrath wrote:

        > Am 31.05.2011 11:16, schrieb Gary Johnson:
        > > Under what conditions does yours crash?
        >
        > Plain vim.exe from MSYS executed in a cmd.exe shell.
        >
        > I have seen something similar to your observations: If I unset HOME in
        > cmd.exe (via "set HOME=") and then run vim.exe from MSYS, it crashes.
        > If I first run bash and then start vim.exe from bash, it works, even
        > if bash also has its HOME variable unset. Strange...
        >
        > However, currently the init_homedir function in misc1.c does not
        > consider the case when both UNIX is defined at build time (#ifdef
        > UNIX) but (var == NULL) at run time, which is perfectly possible when
        > vim is compiled in an MSYS environment (which has __unix defined) but
        > executed from a cmd.exe shell without a HOME variable.
        >
        > The attached short patch is very pragmatic but at least provides a
        > fallback solution when the aforementioned case occures, else the
        > init_homedir function may return and the homedir variable is still NULL.

        It's perfectly OK for homedir to be NULL. Setting it to any random
        directory is not a good idea.

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

        --
        All true wisdom is found on T-shirts.

        /// 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
        ... 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 3 of 20 , Jun 6, 2011
          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 4 of 20 , Jun 6, 2011
            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 5 of 20 , Jun 6, 2011
              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 6 of 20 , Jun 6, 2011
                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 7 of 20 , Jun 7, 2011
                  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 8 of 20 , Jun 7, 2011
                    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 9 of 20 , Jun 8, 2011
                      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 10 of 20 , Jun 8, 2011
                        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 11 of 20 , Jun 8, 2011
                          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 12 of 20 , Oct 21, 2011
                            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 13 of 20 , Oct 21, 2011
                              [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 14 of 20 , 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,
                                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 15 of 20 , Oct 22, 2011
                                  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 16 of 20 , Oct 24, 2011
                                    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 17 of 20 , Oct 24, 2011
                                      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 18 of 20 , Oct 25, 2011
                                        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.