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

Re: 'fileformat' handling. etc.

Expand Messages
  • Bram Moolenaar
    ... The tests may produce warning and error messages. You can ignore these, unless the diff finds a problem later on. ... [adding the filename to the W10
    Message 1 of 11 , Mar 6, 2003
      Walter Briscoe wrote:

      > I have a vim built with nmake /fmake_ivc.mak cfg="Vim - Win32 Debug vim"
      > from the archives ftp://ftp.vim.org/pub/vim/extra/vim-6.1-extra.tar.gz
      > ftp://ftp.vim.org/pub/vim/extra/vim-6.1-lang.tar.gz and
      > ftp://ftp.vim.org/pub/vim/unix/vim-6.1.tar.bz2 Patches 1-362 have been
      > applied. I was interested in the tests run by
      > C:\wfb\vim\bld\vim61\src\testdir\Make_dos.mak. I got a measure of grief
      > in the process.
      > I only refer to the first test as the behaviour applies to them all.
      > The following code is run:
      > 1 copy test1.ok test.ok
      > 2 ..\vimd -u dos.vim -U NONE --noplugin -s dotest.in test1.in
      > 3 diff test.out test1.ok
      > 4 rename test.out test1.out
      > 5 deltree /y X*
      > 6 del test.ok
      > I found line 2 opaque. I still find it somewhat opaque! It produced a
      > couple of "W10: Warning: Changing a readonly file" messages which I did
      > not understand.

      The tests may produce warning and error messages. You can ignore these,
      unless the "diff" finds a problem later on.

      > I sought information by putting the following at the
      > start of dotest.in:
      > redir! > test.log
      > set verbose=20
      > This produced nothing useful.
      > I did the following hack and found that test1.in was the file in
      > question.

      [adding the filename to the W10 message]

      > Is such a change worth making? It solved a problem I never had before.
      > It can be argued that I should always understand the code I run.

      Usually you know what file you are editing. Setting 'verbose' should
      make it clear in cases where you are unsure.
      The reason not to include the filename is that it can be quite long.

      > 3 diff test.out test1.ok
      > fails because the fileformat=dos file test.out compares unequal to the
      > fileformat=unix file test1.ok. I decided to make the default fileformat
      > be unix rather than dos with the following change:

      You should make the test output files dos format before running the
      tests. Packing the .zip files does that for you.

      > I then found loud complaints when I started vim. My _vimrc was a
      > fileformat=dos file. vim interpreted
      > source C:/WFB/exrc as
      > source C:/WFB/exrc^M (according to my verbose redir output.)
      > It was not too hard to correct the offending files.
      > Should this behaviour be viewed as a deficiency?

      No, this is a deliberate choice. Portable vim scripts must use unix
      fileformat, because a mapping may end in a CR and confuse the automatic
      detection mechanism.

      > 5 deltree /y X*
      > This line is W9X specific. For test 1-46,48 del X* is equivalent. Test
      > 47 failed for me. Diagnostics are given and vim does not finish.
      > The suggested patch is:

      There could also be a directory starting with X (don't recall from which
      test). Since this is a Makefile for DOS, it's unlikely to be used for
      systems beyond Windows 9X, since they lack proper DOS support.

      > If I am given any clue on techniques, I will investigate the failure of
      > test 47. :)

      Good.

      --
      BEDEVERE: And what do you burn, apart from witches?
      FOURTH VILLAGER: ... Wood?
      BEDEVERE: So why do witches burn?
      SECOND VILLAGER: (pianissimo) ... Because they're made of wood...?
      "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
      \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
      \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
    • Bram Moolenaar
      ... You don t have a working command.com??? -- BEDEVERE: Wait. Wait ... tell me, what also floats on water? ALL: Bread? No, no, no. Apples .... gravy
      Message 2 of 11 , Mar 6, 2003
        Walter Briscoe wrote:

        > >This line is W9X specific. For test 1-46,48 del X* is equivalent. Test
        > >47 failed for me. Diagnostics are given and vim does not finish.
        > [snip]
        > >If I am given any clue on techniques, I will investigate the failure of
        > >test 47. :)
        > I found I got a couple of E97 messages which showed up nicely with
        > redir! > vim.log and set verbose=20 but were not diagnostic. I stepped
        > through the code and found the following patch hacks it for me on W2K.
        > *** src/testdir/0dos.vim Sun Aug 1 13:01:16 1999
        > --- src/testdir/dos.vim Thu Mar 6 16:16:14 2003
        > ***************
        > *** 1,3 ****
        > " Settings for test script execution
        > " Always use "COMMAND.COM", don't use the value of "$SHELL".
        > ! set shell=c:\COMMAND.COM shellquote= shellxquote= shellcmdflag=/c shellredir=>
        > --- 1,3 ----
        > " Settings for test script execution
        > " Always use "COMMAND.COM", don't use the value of "$SHELL".
        > ! " set shell=c:\COMMAND.COM shellquote= shellxquote= shellcmdflag=/c shellredir=>

        You don't have a working command.com???

        --
        BEDEVERE: Wait. Wait ... tell me, what also floats on water?
        ALL: Bread? No, no, no. Apples .... gravy ... very small rocks ...
        ARTHUR: A duck.
        "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
        \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
      • Walter Briscoe
        In message of Thu, 6 Mar 2003 22:41:23 in , Bram Moolenaar writes [snip] ... Not in Windows
        Message 3 of 11 , Mar 6, 2003
          In message <200303062141.h26LfOl05994@...> of Thu, 6 Mar 2003
          22:41:23 in , Bram Moolenaar <Bram@...> writes
          [snip]
          >> ! " set shell=c:\COMMAND.COM shellquote= shellxquote= shellcmdflag=/c
          >> !shellredir=>
          >
          >You don't have a working command.com???
          >
          Not in Windows 2000!!! It has never troubled me.

          In message <200303062141.h26LfNl05989@...> of Thu, 6 Mar 2003
          22:41:23 in , Bram Moolenaar <Bram@...> writes
          >
          >Walter Briscoe wrote:
          >
          >> I have a vim built with nmake /fmake_ivc.mak cfg="Vim - Win32 Debug vim"
          >> from the archives ftp://ftp.vim.org/pub/vim/extra/vim-6.1-extra.tar.gz
          >> ftp://ftp.vim.org/pub/vim/extra/vim-6.1-lang.tar.gz and
          >> ftp://ftp.vim.org/pub/vim/unix/vim-6.1.tar.bz2 Patches 1-362 have been
          >> applied. I was interested in the tests run by
          >> C:\wfb\vim\bld\vim61\src\testdir\Make_dos.mak. I got a measure of grief
          >> in the process.
          >> I only refer to the first test as the behaviour applies to them all.
          >> The following code is run:
          >> 1 copy test1.ok test.ok
          >> 2 ..\vimd -u dos.vim -U NONE --noplugin -s dotest.in test1.in
          >> 3 diff test.out test1.ok
          >> 4 rename test.out test1.out
          >> 5 deltree /y X*
          >> 6 del test.ok
          >> I found line 2 opaque. I still find it somewhat opaque! It produced a
          >> couple of "W10: Warning: Changing a readonly file" messages which I did
          >> not understand.
          >
          >The tests may produce warning and error messages. You can ignore these,
          >unless the "diff" finds a problem later on.
          >
          >> I sought information by putting the following at the
          >> start of dotest.in:
          >> redir! > test.log
          >> set verbose=20
          >> This produced nothing useful.
          >> I did the following hack and found that test1.in was the file in
          >> question.
          >
          >[adding the filename to the W10 message]
          >
          >> Is such a change worth making? It solved a problem I never had before.
          >> It can be argued that I should always understand the code I run.
          >
          >Usually you know what file you are editing. Setting 'verbose' should
          >make it clear in cases where you are unsure.
          It did not do so. My ignorance was profound. One problem is that no
          verbosity level echoes commands to the redir file. The match between
          stimulus and response was not immediately obvious.

          >The reason not to include the filename is that it can be quite long.
          I agree! I censor the counterarguments.

          >
          >> 3 diff test.out test1.ok
          >> fails because the fileformat=dos file test.out compares unequal to the
          >> fileformat=unix file test1.ok. I decided to make the default fileformat
          >> be unix rather than dos with the following change:
          >
          >You should make the test output files dos format before running the
          >tests. Packing the .zip files does that for you.
          That is ONE workaround. I NOW set fileformat=unix to default.

          >
          >> I then found loud complaints when I started vim. My _vimrc was a
          >> fileformat=dos file. vim interpreted
          >> source C:/WFB/exrc as
          >> source C:/WFB/exrc^M (according to my verbose redir output.)
          >> It was not too hard to correct the offending files.
          >> Should this behaviour be viewed as a deficiency?
          >
          >No, this is a deliberate choice. Portable vim scripts must use unix
          >fileformat, because a mapping may end in a CR and confuse the automatic
          >detection mechanism.
          This seems to be undocumented. I did a case insensitive grep for
          "portable" and found nothing in the doc directory.

          >
          >> 5 deltree /y X*
          >> This line is W9X specific. For test 1-46,48 del X* is equivalent. Test
          >> 47 failed for me. Diagnostics are given and vim does not finish.
          >> The suggested patch is:
          >
          >There could also be a directory starting with X (don't recall from which
          >test). Since this is a Makefile for DOS, it's unlikely to be used for
          >systems beyond Windows 9X, since they lack proper DOS support.
          I have now run tests 1-48 and produced no X* directories. Why does this
          being "a Makefile for DOS" exclude it being a Makefile for NT? I have
          just run the gui tests. No X directories were produced. On the other
          hand, a number of tests failed. Watch this space!

          My hypothesis that deltree is not needed seems false.
          C:\wfb\vim\bld\vim61\src\testdir> grep mkdir *.in
          test12.in::!mkdir Xtest2
          test12.in::!mkdir Xtest.je
          test27.in::!mkdir Xdir1
          test27.in::!mkdir Xdir2
          test27.in::!mkdir Xdir3
          test27.in::!mkdir Xdir4

          However, that reasoning is itself false!

          C:\wfb\vim\bld\vim61\src\testdir> nl -ba Make_dos.mak | sed -n /Omit/p;/12/p;/27
          8 # Omitted:
          11 # test12 can't unlink a swap file
          12 # test25 uses symbolic link
          13 # test27 can't edit file with "*" in file name
          27 test42.out

          C:\wfb\vim\bld\vim61\src\testdir>

          I suggest deltree is bad news as it reduces portability without serving
          any immediate purpose. There is a lack of a decent portable file and
          folder zapper portable among Microsoft shells.

          >> test 47. :)
          >
          >Good.
          Above, you see I have an immediate workaround.
          >

          --
          Walter Briscoe
        • Bram Moolenaar
          ... I thought you were using a Makefile for DOS. That won t work on Windows 2000. ... That s the Cygwin solution . It does require you stick to
          Message 4 of 11 , Mar 7, 2003
            Walter Briscoe wrote:

            > >> ! " set shell=c:\COMMAND.COM shellquote= shellxquote= shellcmdflag=/c
            > >> !shellredir=>
            > >
            > >You don't have a working command.com???
            > >
            > Not in Windows 2000!!! It has never troubled me.

            I thought you were using a Makefile for DOS. That won't work on Windows
            2000.

            > >> 3 diff test.out test1.ok
            > >> fails because the fileformat=dos file test.out compares unequal to the
            > >> fileformat=unix file test1.ok. I decided to make the default fileformat
            > >> be unix rather than dos with the following change:
            > >
            > >You should make the test output files dos format before running the
            > >tests. Packing the .zip files does that for you.
            > That is ONE workaround. I NOW set fileformat=unix to default.

            That's the "Cygwin solution". It does require you stick to
            Unix-compatible tools.

            > >No, this is a deliberate choice. Portable vim scripts must use unix
            > >fileformat, because a mapping may end in a CR and confuse the automatic
            > >detection mechanism.
            > This seems to be undocumented. I did a case insensitive grep for
            > "portable" and found nothing in the doc directory.

            It's not easy to find. Reading the user manual chapter "Write a Vim
            script" you find it just above ":help write-local-help". It's also in
            the chapter about "Using Vim scripts", at ":help :source_crnl".

            > >> 5 deltree /y X*
            > >> This line is W9X specific. For test 1-46,48 del X* is equivalent. Test
            > >> 47 failed for me. Diagnostics are given and vim does not finish.
            > >> The suggested patch is:
            > >
            > >There could also be a directory starting with X (don't recall from which
            > >test). Since this is a Makefile for DOS, it's unlikely to be used for
            > >systems beyond Windows 9X, since they lack proper DOS support.
            > I have now run tests 1-48 and produced no X* directories. Why does this
            > being "a Makefile for DOS" exclude it being a Makefile for NT? I have
            > just run the gui tests. No X directories were produced. On the other
            > hand, a number of tests failed. Watch this space!

            I would have to check again. Some of the tests are skipped for DOS,
            perhaps it's one of these (but then deltree wouldn't be needed). Your
            remarks confirm this.

            Note that Windows 2000/NT/XP do not have DOS support. There is a
            console, but that's not DOS! There is no command.com, for example.

            > I suggest deltree is bad news as it reduces portability without serving
            > any immediate purpose. There is a lack of a decent portable file and
            > folder zapper portable among Microsoft shells.

            I don't think we should try to support using a DOS makefile on non-DOS
            systems. I would actually prefer producing an error message such as
            "you are using the wrong Makefile!".

            --
            I once paid $12 to peer at the box that held King Tutankhamen's little
            bandage-covered midget corpse at the De Young Museum in San Francisco. I
            remember thinking how pleased he'd be about the way things turned out in his
            afterlife.
            (Scott Adams - The Dilbert principle)

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
            \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
            \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
          • Walter Briscoe
            In message of Fri, 7 Mar 2003 11:52:56 in , Bram Moolenaar writes ... In some situations you are
            Message 5 of 11 , Mar 11, 2003
              In message <200303071052.h27AquA00712@...> of Fri, 7 Mar 2003
              11:52:56 in , Bram Moolenaar <Bram@...> writes
              >
              >Walter Briscoe wrote:
              >
              >> >> ! " set shell=c:\COMMAND.COM shellquote= shellxquote= shellcmdflag=/c
              >> >> !shellredir=>
              >> >
              >> >You don't have a working command.com???
              >> >
              >> Not in Windows 2000!!! It has never troubled me.
              >
              >I thought you were using a Makefile for DOS. That won't work on Windows
              >2000.
              In some situations you are right. In this situation, I think we can
              avoid the unnecessary incompatibilities between W9X and W2K. I have
              ported vim to an old W95 machine (I can't believe its slowness. It was
              blisteringly fast compared with its predecessor which was dumped.) I
              made the following change which I recommend. If it is acceptable, I will
              change the various implementations of mch_call_shell.

              *** src/0os_win32.c Sun Mar 9 18:28:40 2003
              --- src/os_win32.c Tue Mar 11 13:15:08 2003
              ***************
              *** 3025,3030 ****
              --- 3025,3038 ----
              else
              #endif
              sprintf((char *)newcmd, "%s %s %s", p_sh, p_shcf, cmd);
              +
              + if (p_verbose > 3)
              + {
              + smsg((char_u *)_("system executing: \"%s\""), newcmd);
              + out_char('\n');
              + cursor_on();
              + }
              +
              x = mch_system((char *)newcmd, options);
              }
              vim_free(newcmd);

              C:\wfb\vim\bld\vim61\src> vimd -E -u NONE -U NONE +"redir!>vim.log" +"set verbose=20" +"!dir vim.log" +q && type vim.log


              Calling shell

              system executing: "C:\winnt\system32\cmd.exe /c dir vim.log" Volume in drive C has no label.
              Volume Serial Number is 07D0-090C

              Directory of C:\wfb\vim\bld\vim61\src

              2003/03/11 14:26 0 vim.log
              1 File(s) 0 bytes
              0 Dir(s) 2,233,597,952 bytes free


              line 0: !dir vim.log

              :!dir vim.log

              Calling shell to execute: "dir vim.log"
              system executing: "C:\winnt\system32\cmd.exe /c dir vim.log"
              line 0: q

              C:\wfb\vim\bld\vim61\src>

              vim also does the "right" thing on W95.
              I also checked vims produced with Make_w16.mak with similar results.

              [snip]
              >
              >> >No, this is a deliberate choice. Portable vim scripts must use unix
              >> >fileformat, because a mapping may end in a CR and confuse the automatic
              >> >detection mechanism.
              >> This seems to be undocumented. I did a case insensitive grep for
              >> "portable" and found nothing in the doc directory.
              >
              >It's not easy to find. Reading the user manual chapter "Write a Vim
              >script" you find it just above ":help write-local-help". It's also in
              >the chapter about "Using Vim scripts", at ":help :source_crnl".
              Thanks!

              >
              >> >> 5 deltree /y X*
              >> >> This line is W9X specific. For test 1-46,48 del X* is equivalent. Test
              >> >> 47 failed for me. Diagnostics are given and vim does not finish.
              >> >> The suggested patch is:
              >> >
              >> >There could also be a directory starting with X (don't recall from which
              >> >test). Since this is a Makefile for DOS, it's unlikely to be used for
              >> >systems beyond Windows 9X, since they lack proper DOS support.
              >> I have now run tests 1-48 and produced no X* directories. Why does this
              >> being "a Makefile for DOS" exclude it being a Makefile for NT? I have
              >> just run the gui tests. No X directories were produced. On the other
              >> hand, a number of tests failed. Watch this space!
              >
              >I would have to check again. Some of the tests are skipped for DOS,
              >perhaps it's one of these (but then deltree wouldn't be needed). Your
              >remarks confirm this.
              So! Can we have the change so that the Make_dos.mak works for both 9x
              and NTX? I tested and found it does not work on W95 in a COMMAND.COM
              window. (mkdir /tmp is rejected.)

              >
              >Note that Windows 2000/NT/XP do not have DOS support. There is a
              >console, but that's not DOS! There is no command.com, for example.
              Agreed! It is not hard to write simple scripts for COMMAND.COM which
              also work for cmd.exe. I just want Make_dos.mak to move in this
              direction.

              >
              >> I suggest deltree is bad news as it reduces portability without serving
              >> any immediate purpose. There is a lack of a decent portable file and
              >> folder zapper portable among Microsoft shells.
              >
              >I don't think we should try to support using a DOS makefile on non-DOS
              >systems. I would actually prefer producing an error message such as
              >"you are using the wrong Makefile!".
              src/Make_ivc.mak etc. work on both W9X and NTX. I find
              testdir/Make_dos.mak is easily changed to work similarly. I see no non-
              theological point in creating a testdir/Make_nt.mak. There is a
              remarkable similarity of logic in this area in os_msdos.c os_win16.c and
              os_win32.c

              >

              I ran testdir/Make_dos.mak with appropriate amendments on a gvim
              generated with Make_ivc.mak.

              On W2K, I had only one failure. The diff listing is not diagnostic.
              vimdiff would be much more obvious. Unfortunately, It shows no
              difference. I will investigate! Meanwhile, the following shows!

              startstart |startstart
              start of testfile |start of testfile
              line 2 Abcdefghijklmnopqrstuvwxyz |line 2 Abcdefghijklmnopqrstuvwxyz
              line 3 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |line 3 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
              line 4 Abcdefghijklmnopqrstuvwxyz |line 4 Abcdefghijklmnopqrstuvwxyz
              line 5 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |line 5 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
              line 6 Abcdefghijklmnopqrstuvwxyz |line 6 Abcdefghijklmnopqrstuvwxyz
              line 7 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |line 7 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
              line 8 Abcdefghijklmnopqrstuvwxyz |line 8 Abcdefghijklmnopqrstuvwxyz
              line 9 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |line 9 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
              line 10 Abcdefghijklmnopqrstuvwxyz |line 10 Abcdefghijklmnopqrstuvwxyz
              end of testfile |end of testfile
              |
              start of test.c |start of test.c
              /* |/*
              * Here is a new .c file | * Here is a new .c file
              */ | */
              end of test.c |end of test.c
              start of testfile |start of testfile
              line 2 Abcdefghijklmnopqrstuvwxyz |line 2 Abcdefghijklmnopqrstuvwxyz
              line 3 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |line 3 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
              line 4 Abcdefghijklmnopqrstuvwxyz |line 4 Abcdefghijklmnopqrstuvwxyz
              linE 5 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX^M|linE 5 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
              linE 6 AbcdefghijklmnopqrstuvwXyz^M |linE 6 AbcdefghijklmnopqrstuvwXyz
              linE 7 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX^M|linE 7 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
              linE 8 AbcdefghijklmnopqrstuvwXyz^M |linE 8 AbcdefghijklmnopqrstuvwXyz
              linE 9 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX^M|linE 9 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
              linE 10 AbcdefghijklmnopqrstuvwXyz^M |linE 10 AbcdefghijklmnopqrstuvwXyz
              End of testfile^M |End of testfile
              ^M |
              /*^M |/*
              * HEre is a NEW .c file^M | * HEre is a NEW .c file
              */^M | */
              /*^M |/*
              * HEre is a new .c file^M | * HEre is a new .c file
              */^M | */
              start of tEstfile^M |start of tEstfile
              linE 2 AbcdefghijklmnopqrstuvwXyz^M |linE 2 AbcdefghijklmnopqrstuvwXyz
              linE 3 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX^M|linE 3 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
              linE 4 AbcdefghijklmnopqrstuvwXyz^M |linE 4 AbcdefghijklmnopqrstuvwXyz
              linE 5 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX^M|linE 5 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
              linE 6 AbcdefghijklmnopqrstuvwXyz^M |linE 6 AbcdefghijklmnopqrstuvwXyz
              linE 7 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX^M|linE 7 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
              linE 8 AbcdefghijklmnopqrstuvwXyz^M |linE 8 AbcdefghijklmnopqrstuvwXyz
              linE 9 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX^M|linE 9 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
              linE 10 AbcdefghijklmnopqrstuvwXyz^M |linE 10 AbcdefghijklmnopqrstuvwXyz
              End of testfile^M |End of testfile
              /*^M |/*
              test.out 1,1 Top test11.ok [RO] 1,1 Top

              It took me some time to figure that my diff does not consider line
              endings as significant!

              On W95, things were less successful! I merely report the problems at the
              moment. I might get something useful before attempting analyses!


              C:\wfb\vim\bld\vim61\src\testdir>grep -i fail make_dos.mak
              FAILURES = test23.out test3.out test17.out test32.out

              C:\wfb\vim\bld\vim61\src\testdir>nmake -fmake_dos.mak test23.out

              Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
              Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

              copy test23.ok test.ok
              1 file(s) copied
              ..\gvimd -u dos.vim -U NONE --noplugin -s dotest.in test23.in
              diff test.out test23.ok
              1,16c1,2
              < Tests for complicated + argument to :edit command
              <
              < STARTTEST
              < :$-1w! Xfile1
              < :$w! Xfile2
              < :edit +1|s/|/PIPE/|w Xfile1| e Xfile2|1 | s/\//SLASH/|w
              < :w! test.out
              < :e Xfile1
              < :w >> test.out
              < :qa!
              < ENDTEST
              <
              < The result should be in Xfile1: "fooPIPEbar", in Xfile2: "fooSLASHbar"
              < foo|bar
              < foo/bar
              < foo|bar
              ---
              > fooSLASHbar
              > fooPIPEbar
              NMAKE : fatal error U1077: 'C:\WFB\BIN\diff.exe' : return code '0x1'
              Stop.
              C:\wfb\vim\bld\vim61\src\testdir>nmake -fmake_dos.mak test3.out

              Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
              Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

              copy test3.ok test.ok
              1 file(s) copied
              ..\gvimd -u dos.vim -U NONE --noplugin -s dotest.in test3.in
              diff test.out test3.ok
              254,256c254,256
              < int i;
              < cmd;
              < }
              ---
              > int i;
              > cmd;
              > }
              258,262c258,262
              < test) { /* this line doesn't work right */
              < int i;
              < cmd;
              < }
              < break;
              ---
              > test) { /* this line doesn't work right */
              > int i;
              > cmd;
              > }
              > break;
              363,365c363,365
              < asdfasdf)
              < aasdf;
              < a = 9;
              ---
              > asdfasdf)
              > aasdf;
              > a = 9;
              367,368c367,368
              < aasdf;
              < a = 9;
              ---
              > aasdf;
              > a = 9;
              370c370
              < y = 2;
              ---
              > y = 2;
              373c373
              < here;
              ---
              > here;
              376,378c376,378
              < asdfasdf)
              < {
              < }
              ---
              > asdfasdf)
              > {
              > }
              381,383c381,383
              < asdfasdf) {
              < there;
              < }
              ---
              > asdfasdf) {
              > there;
              > }
              386,387c386,387
              < asdfasdf)
              < there;
              ---
              > asdfasdf)
              > there;
              504c504
              < bar;
              ---
              > bar;
              525,529c525,528
              < * a real
              < * serious about
              < * life, the
              < * universe, and
              < * the rest important big
              ---
              > * a real serious
              > * about life, the
              > * universe, and the
              > * rest important big
              560c559
              < + vec2[2] * vec[2];
              ---
              > + vec2[2] * vec[2];
              569c568
              < }
              ---
              > }
              575c574
              < }
              ---
              > }
              581,588c580,587
              < * Comment for
              < * first par
              < */
              < int second_par /*
              < * Comment for
              < * second par
              < */
              < )
              ---
              > * Comment for
              > * first par
              > */
              > int second_par /*
              > * Comment for
              > * second par
              > */
              > )
              591,598c590,597
              < * Comment for
              < * first par
              < */
              < second_par /*
              < * Comment for
              < * second par
              < */
              < );
              ---
              > * Comment for
              > * first par
              > */
              > second_par /*
              > * Comment for
              > * second par
              > */
              > );
              697,699c696,698
              < f(/*com*/);
              < if (/*com*/)
              < cmd();
              ---
              > f(/*com*/);
              > if (/*com*/)
              > cmd();
              763,764c762,763
              < && ( c2
              < || c3))
              ---
              > && ( c2
              > || c3))
              772,773c771,772
              < && ( c2
              < || c3))
              ---
              > && ( c2
              > || c3))
              NMAKE : fatal error U1077: 'C:\WFB\BIN\diff.exe' : return code '0x1'
              Stop.

              C:\wfb\vim\bld\vim61\src\testdir>nmake -fmake_dos.mak test17.out

              Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
              Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

              copy test17.ok test.ok
              1 file(s) copied
              ..\gvimd -u dos.vim -U NONE --noplugin -s dotest.in test17.in
              diff test.out test17.ok
              1,27c1,3
              < Tests for "gf" on ${VAR}
              <
              < STARTTEST
              < :so small.vim
              < :if has("ebcdic")
              < : set isfname=@,240-249,/,.,-,_,+,,,$,:,~,{,}
              < :else
              < : set isfname=@,48-57,/,.,-,_,+,,,$,:,~,{,}
              < :endif
              < :if has("unix")
              < :let $CDIR = "."
              < /CDIR
              < :else
              < :if has("amiga")
              < :let $TDIR = "/testdir"
              < :else
              < :let $TDIR = "."
              < :endif
              < /TDIR
              < :endif
              < gf
              < :w! test.out
              < :qa!
              < ENDTEST
              <
              < ${CDIR}/test17a.in
              < $TDIR/test17a.in
              ---
              > This file is just to test "gf" in test 17.
              > The contents is not importent.
              > Just testing!
              NMAKE : fatal error U1077: 'C:\WFB\BIN\diff.exe' : return code '0x1'
              Stop.

              test32 goes into an infinite loop.



              --
              Walter Briscoe
            • Bram Moolenaar
              ... There already is a verbose message on a level higher, in the system-independend call_shell() function. The only thing happening at the lower level is
              Message 6 of 11 , Mar 12, 2003
                Walter Briscoe wrote:

                > I made the following change which I recommend. If it is acceptable, I
                > will change the various implementations of mch_call_shell.

                There already is a verbose message on a level higher, in the
                system-independend call_shell() function. The only thing happening at
                the lower level is adding 'shell' and 'shellcmdflag'. That is
                predictable, thus an extra message won't help much. And you don't get
                anything in some cases (e.g., when using "start").

                I still don't see the point in building a win16 application on Windows
                2000/NT/Xp.

                > >Note that Windows 2000/NT/XP do not have DOS support. There is a
                > >console, but that's not DOS! There is no command.com, for example.
                > Agreed! It is not hard to write simple scripts for COMMAND.COM which
                > also work for cmd.exe. I just want Make_dos.mak to move in this
                > direction.

                I think it is a waste of time. The 16 bit version has too many
                limitations. It shouldn't be used on a non-DOS system.

                > src/Make_ivc.mak etc. work on both W9X and NTX. I find
                > testdir/Make_dos.mak is easily changed to work similarly. I see no non-
                > theological point in creating a testdir/Make_nt.mak. There is a
                > remarkable similarity of logic in this area in os_msdos.c os_win16.c and
                > os_win32.c

                > I ran testdir/Make_dos.mak with appropriate amendments on a gvim
                > generated with Make_ivc.mak.

                What is the point of this?

                > It took me some time to figure that my diff does not consider line
                > endings as significant!

                That's why a diff.exe is included with the Vim distribution.

                --
                Portable Computer: A device invented to force businessmen
                to work at home, on vacation, and on business trips.

                /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
              • Walter Briscoe
                In message of Wed, 12 Mar 2003 23:06:17 in , Bram Moolenaar writes ... It is convenient to do
                Message 7 of 11 , Mar 13, 2003
                  In message <200303122206.h2CM6HB11184@...> of Wed, 12 Mar 2003
                  23:06:17 in , Bram Moolenaar <Bram@...> writes
                  >
                  >Walter Briscoe wrote:
                  >
                  >> I made the following change which I recommend. If it is acceptable, I
                  >> will change the various implementations of mch_call_shell.
                  >
                  >There already is a verbose message on a level higher, in the
                  >system-independend call_shell() function. The only thing happening at
                  >the lower level is adding 'shell' and 'shellcmdflag'. That is
                  >predictable, thus an extra message won't help much. And you don't get
                  >anything in some cases (e.g., when using "start").
                  >
                  >I still don't see the point in building a win16 application on Windows
                  >2000/NT/Xp.
                  It is convenient to do so! I usually just check that code changes work
                  with one Makefile on one system and build with others on that system.

                  >
                  >> >Note that Windows 2000/NT/XP do not have DOS support. There is a
                  >> >console, but that's not DOS! There is no command.com, for example.
                  >> Agreed! It is not hard to write simple scripts for COMMAND.COM which
                  >> also work for cmd.exe. I just want Make_dos.mak to move in this
                  >> direction.
                  >
                  >I think it is a waste of time. The 16 bit version has too many
                  >limitations. It shouldn't be used on a non-DOS system.
                  I am sorry I seem to be causing confusion.

                  I find src/testdir/Make_dos.mak does not work:
                  a) on w2k with cmd.exe because it uses the w9x specific application
                  deltree;
                  b) on w2k with cmd.exe because dos.vim uses COMMAND.COM
                  I have checked and found that dos.vim is not necessary for a vim
                  built with Make_ivc.mak on either W2K or W95
                  c) on w95 with COMMAND.COM because it uses a slash rather than a
                  backslash in "mkdir /tmp"

                  I have tested a corrected Make_dos.mak with executables built with both
                  Make_ivc.mak and Make_w16.mak. I reported test failures on executables
                  built with Make_ivc.mak. The behaviour is fairly different between W95
                  and W2K. If given the odd clue, I can investigate. I find the executable
                  built with Make_w16.mak is untestable with Make_dos.mak on my W95
                  machine. (It results in a seizure which needs a reboot to fix.) I am
                  leaving that as a subsidiary problem.

                  >
                  >> src/Make_ivc.mak etc. work on both W9X and NTX. I find
                  >> testdir/Make_dos.mak is easily changed to work similarly. I see no non-
                  >> theological point in creating a testdir/Make_nt.mak. There is a
                  >> remarkable similarity of logic in this area in os_msdos.c os_win16.c and
                  >> os_win32.c
                  >
                  >> I ran testdir/Make_dos.mak with appropriate amendments on a gvim
                  >> generated with Make_ivc.mak.
                  >
                  >What is the point of this?
                  To find problems in the w32 port of vim.
                  Those tests are a LOT harder than my simple use of Vim.

                  >
                  >> It took me some time to figure that my diff does not consider line
                  >> endings as significant!
                  I have looked further and am REALLY confused. The diff is from a cygwin
                  port. I shall have to investigate further!

                  >
                  >That's why a diff.exe is included with the Vim distribution.
                  For me, the problem with that is lack of source code.
                  I do not seem to have information to reproduce a Vim distribution.
                  Again, I only want to do so to exercise the software in a largely futile
                  search for failures.
                  --
                  Walter Briscoe
                • Bram Moolenaar
                  ... As mentioned before it s possible to use del X* instead. But we need to check that no directories are left behind. ... But when $SHELL is something like
                  Message 8 of 11 , Mar 13, 2003
                    Walter Briscoe wrote:

                    > >I still don't see the point in building a win16 application on Windows
                    > >2000/NT/Xp.
                    > It is convenient to do so! I usually just check that code changes work
                    > with one Makefile on one system and build with others on that system.

                    > I find src/testdir/Make_dos.mak does not work:
                    > a) on w2k with cmd.exe because it uses the w9x specific application
                    > deltree;

                    As mentioned before it's possible to use "del X*" instead. But we need
                    to check that no directories are left behind.

                    > b) on w2k with cmd.exe because dos.vim uses COMMAND.COM
                    > I have checked and found that dos.vim is not necessary for a vim
                    > built with Make_ivc.mak on either W2K or W95

                    But when $SHELL is something like "sh" the tests will fail. An idea
                    would be to add a check whether command.com exists, but it must also
                    work when compiled without +eval...

                    > c) on w95 with COMMAND.COM because it uses a slash rather than a
                    > backslash in "mkdir /tmp"

                    That's a new one. On my system "/tmp" exists, thus I never ran into
                    this problem.

                    > I have tested a corrected Make_dos.mak with executables built with both
                    > Make_ivc.mak and Make_w16.mak. I reported test failures on executables
                    > built with Make_ivc.mak. The behaviour is fairly different between W95
                    > and W2K. If given the odd clue, I can investigate. I find the executable
                    > built with Make_w16.mak is untestable with Make_dos.mak on my W95
                    > machine. (It results in a seizure which needs a reboot to fix.) I am
                    > leaving that as a subsidiary problem.

                    I can't give you a clue...

                    > >> It took me some time to figure that my diff does not consider line
                    > >> endings as significant!
                    > I have looked further and am REALLY confused. The diff is from a cygwin
                    > port. I shall have to investigate further!

                    Cygwin diff has been reported to have problems. May not appear in all
                    versions though.

                    > >That's why a diff.exe is included with the Vim distribution.
                    > For me, the problem with that is lack of source code.
                    > I do not seem to have information to reproduce a Vim distribution.

                    The source code for this diff.exe isn't included. You need to get the
                    executable from a Vim archive.

                    --
                    hundred-and-one symptoms of being an internet addict:
                    46. Your wife makes a new rule: "The computer cannot come to bed."

                    /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                    /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                    \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                    \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
                  Your message has been successfully submitted and would be delivered to recipients shortly.