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

Another 9 in todo.txt

Expand Messages
  • Walter Briscoe
    Win32 console: 9 When editing a file by its short file name, it should be expanded into its long file name, to avoid problems like these: (Mccollister) 1)
    Message 1 of 15 , Mar 27, 2003
    • 0 Attachment
      Win32 console:
      9 When editing a file by its short file name, it should be expanded into its
      long file name, to avoid problems like these: (Mccollister)
      1) Create a file called ".bashrc" using some other editor.
      2) Drag that file onto a shortcut or the actual executable.
      3) Note that the file name is something like BASHRC~1
      4) Go to File->Save As menu item and type ".bashrc" as the file name.
      5) Press "Yes" to indicate that I want to overwrite the file.
      6) Note that the message "File exists (use ! to override)" is displayed
      and the file is not saved.
      Use FindFirstFile() to expand a file name and directory in the path to its
      long name.
      3) did not happen with a Make_ivc.mak-made vimd.exe on W2K SP3.
      It did happen with a Make_djg.mak-made vim.exe.

      Both think BASHRC~1 and .bashrc are different files.
      It also happens if do %vim% BASHRC~1, and write to .bashrc.

      I think the short form of a filename should be "normalised".
      For example, the normalised form of
      A12345~1\B\..\C12345~1 might be
      a12345678\c12345678.

      I have a patch; it contains some extra changes in response to
      diagnostics from PC-lint; it also contains probing code as I have yet to
      learn to use gdb. (Now I have a working DJG installation, I promise to
      learn gdb real soon now!) It works with a Make_ivc.mak-made vimd.exe; it
      currently fails with a Make_djg.mak-made vim.exe; the reason for failure
      is that the two versions of fix_fname() deliver different results from
      the same input.
      "bashrc~1" is transformed to
      "C:\wfb\vim\bld\vim61\src\.bashrc" by vimd.exe and to
      "c:\wfb\vim\bld\vim61\src\bashrc~1" by vim.exe
      I presume the former is better and will look at changing the latter.

      Can Bram or any other reader see a fundamental flaw in the approach I
      have taken? (Translate any short filenames or names containing "../"
      into the corresponding long file names.) If there is such a flaw which
      we can't resolve, I will scrap the work.

      I think my code can be improved; I have two loops which can probably be
      merged to reduce the footprint of the work.

      The problems I hit gives me the opportunity to refer to my proposed
      changes to Make_djg.mak. I have no response from Bram to message
      <GfPSn0HNTAg+Ewhl@...> of Tue, 25 Mar 2003 07:27:09.

      *** src/0buffer.c Sat Mar 15 19:03:04 2003
      --- src/buffer.c Thu Mar 27 10:20:44 2003
      ***************
      *** 49,60 ****
      static void free_buffer_stuff __ARGS((buf_T *buf, int free_options));
      static void clear_wininfo __ARGS((buf_T *buf));

      - #ifdef UNIX
      - # define dev_T dev_t
      - #else
      - # define dev_T unsigned
      - #endif
      -
      /*
      * Open current buffer, that is: open the memfile and read the file into memory
      * return FAIL for failure, OK otherwise
      --- 49,54 ----
      ***************
      *** 1287,1293 ****
      /* On Unix we can use inode numbers when the file exists. Works better
      * for hard links. */
      if (sfname == NULL || mch_stat((char *)sfname, &st) < 0)
      ! st.st_dev = (dev_T)-1;
      #endif
      if (ffname != NULL && !(flags & BLN_DUMMY) && (buf =
      #ifdef UNIX
      --- 1281,1287 ----
      /* On Unix we can use inode numbers when the file exists. Works better
      * for hard links. */
      if (sfname == NULL || mch_stat((char *)sfname, &st) < 0)
      ! st.st_dev = (dev_t)-1;
      #endif
      if (ffname != NULL && !(flags & BLN_DUMMY) && (buf =
      #ifdef UNIX
      ***************
      *** 1427,1433 ****

      buf->b_fname = buf->b_sfname;
      #ifdef UNIX
      ! if (st.st_dev == (dev_T)-1)
      buf->b_dev = -1;
      else
      {
      --- 1421,1427 ----

      buf->b_fname = buf->b_sfname;
      #ifdef UNIX
      ! if (st.st_dev == (dev_t)-1)
      buf->b_dev = -1;
      else
      {
      ***************
      *** 1665,1671 ****
      struct stat st;

      if (mch_stat((char *)ffname, &st) < 0)
      ! st.st_dev = (dev_T)-1;
      return buflist_findname_stat(ffname, &st);
      }

      --- 1659,1665 ----
      struct stat st;

      if (mch_stat((char *)ffname, &st) < 0)
      ! st.st_dev = (dev_t)-1;
      return buflist_findname_stat(ffname, &st);
      }

      ***************
      *** 2259,2265 ****
      curbuf->b_ffname = NULL;
      curbuf->b_sfname = NULL;
      #ifdef UNIX
      ! st.st_dev = (dev_T)-1;
      #endif
      }
      else
      --- 2253,2259 ----
      curbuf->b_ffname = NULL;
      curbuf->b_sfname = NULL;
      #ifdef UNIX
      ! st.st_dev = (dev_t)-1;
      #endif
      }
      else
      ***************
      *** 2275,2281 ****
      */
      #ifdef UNIX
      if (mch_stat((char *)ffname, &st) < 0)
      ! st.st_dev = (dev_T)-1;
      buf = buflist_findname_stat(ffname, &st);
      #else
      buf = buflist_findname(ffname);
      --- 2269,2275 ----
      */
      #ifdef UNIX
      if (mch_stat((char *)ffname, &st) < 0)
      ! st.st_dev = (dev_t)-1;
      buf = buflist_findname_stat(ffname, &st);
      #else
      buf = buflist_findname(ffname);
      ***************
      *** 2311,2317 ****
      }
      curbuf->b_fname = curbuf->b_sfname;
      #ifdef UNIX
      ! if (st.st_dev == (dev_T)-1)
      curbuf->b_dev = -1;
      else
      {
      --- 2305,2311 ----
      }
      curbuf->b_fname = curbuf->b_sfname;
      #ifdef UNIX
      ! if (st.st_dev == (dev_t)-1)
      curbuf->b_dev = -1;
      else
      {
      ***************
      *** 2482,2488 ****
      if (stp == NULL)
      {
      if (buf->b_dev < 0 || mch_stat((char *)ffname, &st) < 0)
      ! st.st_dev = (dev_T)-1;
      stp = &st;
      }
      /* Use dev/ino to check if the files are the same, even when the names
      --- 2476,2482 ----
      if (stp == NULL)
      {
      if (buf->b_dev < 0 || mch_stat((char *)ffname, &st) < 0)
      ! st.st_dev = (dev_t)-1;
      stp = &st;
      }
      /* Use dev/ino to check if the files are the same, even when the names
      ***************
      *** 3653,3658 ****
      --- 3647,3654 ----
      return TRUE;
      }

      + static FILE *qq;
      +
      /*
      * If fname is not a full path, make it a full path.
      * Returns pointer to allocated memory (NULL for failure).
      ***************
      *** 3676,3682 ****
      --- 3672,3683 ----
      || vim_strchr(fname, '~') != NULL
      #endif
      )
      + {
      + if (!qq)
      + qq = fopen("q.q", "wt");
      + fprintf(qq, "sfname = \"%s\"\n", "FullName_save");
      return FullName_save(fname, FALSE);
      + }

      fname = vim_strsave(fname);

      ***************
      *** 3712,3721 ****
      #ifdef FEAT_SHORTCUT
      if (!curbuf->b_p_bin)
      {
      - char_u *rfname = NULL;
      -
      /* If the file name is a shortcut file, use the file it links to. */
      ! rfname = mch_resolve_shortcut(*ffname);
      if (rfname)
      {
      vim_free(*ffname);
      --- 3713,3721 ----
      #ifdef FEAT_SHORTCUT
      if (!curbuf->b_p_bin)
      {
      /* If the file name is a shortcut file, use the file it links to. */
      ! char_u *rfname = mch_resolve_shortcut(*ffname);
      !
      if (rfname)
      {
      vim_free(*ffname);
      ***************
      *** 3724,3729 ****
      --- 3724,3791 ----
      }
      }
      #endif
      + #if defined(MSWIN) || defined(DJGPP)
      + if (strstr((char *)*sfname, "..\\") != NULL
      + || vim_strchr(*sfname, '~') != NULL)
      + {
      + /* The short file name is ambiguous */
      + char_u *sfname_full;
      + int folders = 0;
      + char_u *pcu;
      +
      + if (!qq)
      + qq = fopen("q.q", "wt");
      +
      + sfname_full = fix_fname(*sfname);
      + fprintf(qq, "sfname = \"%s\"\n", *sfname);
      + fprintf(qq, "sfname_full = \"%s\"\n", sfname_full);
      + if ((*sfname)[1] == ':')
      + {
      + vim_free(*sfname);
      + *sfname = sfname_full;
      + }
      + else
      + {
      + /* Count the folders in the short name */
      + for (pcu = *sfname; *pcu; ++pcu)
      + {
      + switch (*pcu)
      + {
      + case '.': /* May be ..\; ...\ is W9X jargon. */
      + while (*++pcu == '.')
      + ;
      + if (*pcu == '\\')
      + if (pcu < *sfname + 2
      + || strncmp(pcu - 2, "..\\", 3) != 0)
      + ++folders;
      + break;
      + case '\\': /* Folder name boundary */
      + ++folders;
      + break;
      + }
      + }
      +
      + /* Find the corresponding position in the long name */
      + for (pcu = sfname_full + strlen(sfname_full);
      + pcu && pcu > sfname_full && folders >= 0;
      + --pcu)
      + {
      + if (*pcu == '\\')
      + --folders;
      + }
      +
      + /* Next character is a backslash; current one is not a colon */
      + pcu += 2;
      +
      + /* We should now have a normalised short name */
      + vim_free(*sfname);
      + *sfname = malloc(strlen(pcu) + 1);
      + strcpy(*sfname, pcu);
      + vim_free(sfname_full);
      + }
      + }
      + #endif
      +
      }

      /*

      --
      Walter Briscoe
    • Bram Moolenaar
      ... Yes, all this is supposed to be done by mch_FullName(). Somehow it doesn t work. It seems your patch tries to fix it in the wrong place. I don t see why
      Message 2 of 15 , Mar 27, 2003
      • 0 Attachment
        Walter Briscoe wrote:

        > Win32 console:
        > 9 When editing a file by its short file name, it should be expanded into its
        > long file name, to avoid problems like these: (Mccollister)
        > 1) Create a file called ".bashrc" using some other editor.
        > 2) Drag that file onto a shortcut or the actual executable.
        > 3) Note that the file name is something like BASHRC~1
        > 4) Go to File->Save As menu item and type ".bashrc" as the file name.
        > 5) Press "Yes" to indicate that I want to overwrite the file.
        > 6) Note that the message "File exists (use ! to override)" is displayed
        > and the file is not saved.
        > Use FindFirstFile() to expand a file name and directory in the path to its
        > long name.
        > 3) did not happen with a Make_ivc.mak-made vimd.exe on W2K SP3.
        > It did happen with a Make_djg.mak-made vim.exe.
        >
        > Both think BASHRC~1 and .bashrc are different files.
        > It also happens if do %vim% BASHRC~1, and write to .bashrc.
        >
        > I think the short form of a filename should be "normalised".
        > For example, the normalised form of
        > A12345~1\B\..\C12345~1 might be
        > a12345678\c12345678.

        Yes, all this is supposed to be done by mch_FullName(). Somehow it
        doesn't work.

        It seems your patch tries to fix it in the wrong place. I don't see why
        the code in buffer.c needs to be changed.

        --
        hundred-and-one symptoms of being an internet addict:
        238. You think faxes are old-fashioned.

        /// 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, 27 Mar 2003 23:49:46 in , Bram Moolenaar writes ... The two versions of
        Message 3 of 15 , Mar 28, 2003
        • 0 Attachment
          In message <200303272249.h2RMnkO13143@...> of Thu, 27 Mar 2003
          23:49:46 in , Bram Moolenaar <Bram@...> writes
          >
          >Walter Briscoe wrote:
          >
          >> Win32 console:
          >> 9 When editing a file by its short file name, it should be expanded
          >>into its
          >> long file name, to avoid problems like these: (Mccollister)
          >> 1) Create a file called ".bashrc" using some other editor.
          >> 2) Drag that file onto a shortcut or the actual executable.
          >> 3) Note that the file name is something like BASHRC~1
          >> 4) Go to File->Save As menu item and type ".bashrc" as the file name.
          >> 5) Press "Yes" to indicate that I want to overwrite the file.
          >> 6) Note that the message "File exists (use ! to override)" is displayed
          >> and the file is not saved.
          >> Use FindFirstFile() to expand a file name and directory in the
          >>path to its
          >> long name.
          >> 3) did not happen with a Make_ivc.mak-made vimd.exe on W2K SP3.
          >> It did happen with a Make_djg.mak-made vim.exe.
          >>
          >> Both think BASHRC~1 and .bashrc are different files.
          >> It also happens if do %vim% BASHRC~1, and write to .bashrc.
          >>
          >> I think the short form of a filename should be "normalised".
          >> For example, the normalised form of
          >> A12345~1\B\..\C12345~1 might be
          >> a12345678\c12345678.
          >
          >Yes, all this is supposed to be done by mch_FullName(). Somehow it
          >doesn't work.

          The two versions of mch_FullName() in os_msdos.c and os_mswin.c give
          different outputs from the same input. I think the code in os_msdos.c is
          defective and am working on changing it.

          >
          >It seems your patch tries to fix it in the wrong place. I don't see why
          >the code in buffer.c needs to be changed.
          >
          You are probably right. My horrible buffer.c patch does fix the problem
          when given a working mch_FullName(). I would prefer a fix elsewhere. I
          am not yet convinced it is the wrong place. I think that the real
          problem is that vim views .bashrc and BASHRC~1 as references to two
          different files. Do you agree?

          Currently, mch_FullName() is not used in setting the short file name
          (*sfname in fname_expand()). The result of this is that the short file
          name is not normalised. Ah! A better solution may be to compare
          normalised filenames when a new filename is proposed.
          --
          Walter Briscoe
        • Bram Moolenaar
          ... That s probably the right solution. ... When two file names are really the same file there must be only one buffer for them. It s still possible to access
          Message 4 of 15 , Mar 28, 2003
          • 0 Attachment
            Walter Briscoe wrote:

            > >Yes, all this is supposed to be done by mch_FullName(). Somehow it
            > >doesn't work.
            >
            > The two versions of mch_FullName() in os_msdos.c and os_mswin.c give
            > different outputs from the same input. I think the code in os_msdos.c is
            > defective and am working on changing it.

            That's probably the right solution.

            > >It seems your patch tries to fix it in the wrong place. I don't see why
            > >the code in buffer.c needs to be changed.
            > >
            > You are probably right. My horrible buffer.c patch does fix the problem
            > when given a working mch_FullName(). I would prefer a fix elsewhere. I
            > am not yet convinced it is the wrong place. I think that the real
            > problem is that vim views .bashrc and BASHRC~1 as references to two
            > different files. Do you agree?

            When two file names are really the same file there must be only one
            buffer for them. It's still possible to access that file by different
            names, that cannot be avoided (esp. with symbolic links on Unix).
            Sometimes it's even desired.

            > Currently, mch_FullName() is not used in setting the short file name
            > (*sfname in fname_expand()). The result of this is that the short file
            > name is not normalised. Ah! A better solution may be to compare
            > normalised filenames when a new filename is proposed.

            The short file name should remain whatever the user typed (corrected for
            change-directory commands). The full filename is to be used when
            comparing file names. That should already happen in every situation.
            If you spot a situation where it doesn't happen, it needs to be fixed.

            --
            hundred-and-one symptoms of being an internet addict:
            250. You've given up the search for the "perfect woman" and instead,
            sit in front of the PC until you're just too tired to care.

            /// 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, 28 Mar 2003 20:31:06 in , Bram Moolenaar writes ... I am sorry it has taken
            Message 5 of 15 , Apr 1, 2003
            • 0 Attachment
              In message <200303281931.h2SJV6J05531@...> of Fri, 28 Mar 2003
              20:31:06 in , Bram Moolenaar <Bram@...> writes
              >
              >Walter Briscoe wrote:
              >
              >> >Yes, all this is supposed to be done by mch_FullName(). Somehow it
              >> >doesn't work.
              >>
              >> The two versions of mch_FullName() in os_msdos.c and os_mswin.c give
              >> different outputs from the same input. I think the code in os_msdos.c is
              >> defective and am working on changing it.
              >
              >That's probably the right solution.
              I am sorry it has taken me a long time to respond on this. I have some
              work I am ready to show. It was developed as a stand-alone function and
              then integrated into Vim. I looked at djg 2.03 documentation and found a
              function which seems to hit the spot: _truename. I have done some
              testing with the latest 2.03 build - to avoid the ntvdm.exe problems -
              and with 2.04 alpha. I have exercised the code with W2KSP3 and W95. I
              dare say it needs more testing; I have not been able to break it as I
              easily could with the old code. The code is seriously shorter.

              *** src/0os_msdos.c Sat Mar 29 11:10:26 2003
              --- src/os_msdos.c Tue Apr 1 20:29:42 2003
              ***************
              *** 1582,1588 ****
              int len,
              int force)
              {
              ! if (!force && mch_isFullName(fname)) /* allready expanded */
              {
              STRNCPY(buf, fname, len);
              buf[len - 1] = NUL;
              --- 1582,1588 ----
              int len,
              int force)
              {
              ! if (!force && mch_isFullName(fname)) /* already expanded */
              {
              STRNCPY(buf, fname, len);
              buf[len - 1] = NUL;
              ***************
              *** 1596,1719 ****
              return OK;
              #else /* almost the same as mch_FullName() in os_unix.c */
              {
              ! int l;
              ! char_u olddir[MAXPATHL];
              ! char_u *p, *q;
              ! int c;
              ! int retval = OK;

              ! *buf = 0;
              ! /*
              ! * change to the directory for a moment,
              ! * and then do the getwd() (and get back to where we were).
              ! * This will get the correct path name with "../" things.
              ! */
              ! p = vim_strrchr(fname, '/');
              ! q = vim_strrchr(fname, '\\');
              ! if (q != NULL && (p == NULL || q > p))
              ! p = q;
              ! q = vim_strrchr(fname, ':');
              ! if (q != NULL && (p == NULL || q > p))
              ! p = q;
              ! if (p != NULL)
              ! {
              ! if (getcwd(olddir, MAXPATHL) == NULL)
              ! {
              ! p = NULL; /* can't get current dir: don't chdir */
              ! retval = FAIL;
              ! }
              ! else
              ! {
              ! if (p == fname) /* /fname */
              ! q = p + 1; /* -> / */
              ! else if (q + 1 == p) /* ... c:\foo */
              ! q = p + 1; /* -> c:\ */
              ! else /* but c:\foo\bar */
              ! q = p; /* -> c:\foo */
              !
              ! c = *q; /* truncate at start of fname */
              ! *q = NUL;
              ! #ifdef DJGPP
              ! STRCPY(buf, fname);
              ! slash_adjust(buf); /* needed when fname starts with \ */
              ! if (mch_chdir(buf)) /* change to the directory */
              ! #else
              ! if (mch_chdir(fname)) /* change to the directory */
              ! #endif
              ! retval = FAIL;
              ! else
              ! {
              ! fname = q;
              ! if (c == psepc) /* if we cut the name at a */
              ! fname++; /* '\', don't add it again */
              ! }
              ! *q = c;
              ! }
              ! }
              ! if (getcwd(buf, len) == NULL)
              ! {
              ! retval = FAIL;
              ! *buf = NUL;
              ! }
              ! #ifdef USE_FNAME_CASE
              ! else
              ! {
              ! char_u *head;
              ! char_u *tail;
              ! struct ffblk fb;
              ! int c;
              ! int added;
              !
              ! /* Apparently "longna~1" isn't expanded by getcwd(), at least not
              ! * for DJGPP. Expand it here. Have to do each dirname
              ! * separately. */
              ! slash_adjust(buf);
              ! head = buf;
              ! if (isalpha(*head) && head[1] == ':')
              ! head += 2; /* skip "c:" */
              ! while (*head != NUL)
              ! {
              ! /* Advance "head" to the start of a dirname and "tail" to just
              ! * after it. */
              ! while (*head == '/' || *head == '\\')
              ! ++head;
              ! for (tail = head; *tail != NUL; ++tail)
              ! if (*tail == '/' || *tail == '\\')
              ! break;
              ! c = *tail;
              ! *tail = NUL;
              !
              ! if (findfirst(buf, &fb, FA_DIREC) == 0)
              ! {
              ! added = STRLEN(fb.ff_name);
              ! if ((head - buf) + added + STRLEN(tail + 1) + 2 < len)
              ! {
              ! added -= (tail - head);
              ! if (added != 0)
              ! mch_memmove(tail + 1 + added, tail + 1,
              ! STRLEN(tail + 1) + 1);
              ! STRCPY(head, fb.ff_name);
              ! tail += added;
              ! }
              ! }
              ! *tail = c;
              ! head = tail;
              ! }
              ! }
              ! #endif
              ! if (p != NULL)
              ! mch_chdir(olddir);
              ! /*
              ! * Concatenate the file name to the path.
              ! */
              ! if (*fname != NUL)
              ! {
              ! l = STRLEN(buf);
              ! if (l > 0 && buf[l - 1] != '/' && buf[l - 1] != '\\')
              ! strcat(buf, pseps);
              ! strcat(buf, fname);
              ! }
              ! return retval;
              }
              #endif
              }
              --- 1596,1609 ----
              return OK;
              #else /* almost the same as mch_FullName() in os_unix.c */
              {
              ! char_u fullpath[MAXPATHL];

              ! if (!_truename(fname, fullpath))
              ! return FAIL;
              ! slash_adjust(fullpath); /* Only needed when 'shellslash' set */
              ! STRNCPY(buf, fullpath, len);
              ! buf[len - 1] = NUL;
              ! return OK;
              }
              #endif
              }

              This is a frightening truncation of the code. If Bram (or anybody else)
              can point me at a URL for an obsolescent version of DJGPP, I will also
              test against that.

              I found difficulties building with the 2.04 alpha.
              gcc -c -O2 -DMSDOS -Iproto -Wall -Dinterrupt= -Dfar= -DMAXMEM=512 -D_NAIVE_DOS_REGS misc2.c -o obj/misc2.o
              misc2.c: In function `putenv':
              misc2.c:5371: argument `string' doesn't match prototype
              c:/djgpp/include/stdlib.h:104: prototype declaration
              make.exe: *** [obj/misc2.o] Error 1

              C:\wfb\vim\bld\vim61\src> sed 104!d < c:/djgpp/include/stdlib.h
              int putenv(char *_val);

              C:\wfb\vim\bld\vim61\src> sed 5368,5371!d < misc2.c
              int
              putenv(string)
              const char *string;
              {

              IEEE Std 1003.1-2001 has
              #include <stdlib.h>

              int putenv(char *string);

              My first response is to patch misc2.c. I see proto.h also has const. I
              will not submit patches for this.

              >
              >> >It seems your patch tries to fix it in the wrong place. I don't see why
              >> >the code in buffer.c needs to be changed.
              >> >
              >> You are probably right. My horrible buffer.c patch does fix the problem
              >> when given a working mch_FullName(). I would prefer a fix elsewhere. I
              >> am not yet convinced it is the wrong place. I think that the real
              >> problem is that vim views .bashrc and BASHRC~1 as references to two
              >> different files. Do you agree?
              >
              >When two file names are really the same file there must be only one
              >buffer for them. It's still possible to access that file by different
              >names, that cannot be avoided (esp. with symbolic links on Unix).
              >Sometimes it's even desired.
              >
              >> Currently, mch_FullName() is not used in setting the short file name
              >> (*sfname in fname_expand()). The result of this is that the short file
              >> name is not normalised. Ah! A better solution may be to compare
              >> normalised filenames when a new filename is proposed.
              >
              >The short file name should remain whatever the user typed (corrected for
              >change-directory commands). The full filename is to be used when
              >comparing file names. That should already happen in every situation.
              >If you spot a situation where it doesn't happen, it needs to be fixed.
              >

              Fixing mch_FullName() fixes the problem; w .bashrc while editing
              bashrc~1 works with a vim.exe built with Make_djg.mak and DJGPP 2.04
              alpha. It also works if the process is inverted. It also works with a
              vimd.exe built with nmake /f Make_ivc.mak cfg="Vim - Win32 Debug vim".
              I think we have a fix that is worth others trying to break.
              --
              Walter Briscoe
            • Vince Negri
              ... Walter (and all), For some reason I had to apply the patch manually (probably my mail client trashing the tabs), but I can confirm a successful test
              Message 6 of 15 , Apr 1, 2003
              • 0 Attachment
                > This is a frightening truncation of the code. If Bram (or anybody else)
                > can point me at a URL for an obsolescent version of DJGPP, I will also
                > test against that.

                > Fixing mch_FullName() fixes the problem; w .bashrc while editing
                > bashrc~1 works with a vim.exe built with Make_djg.mak and DJGPP 2.04
                > alpha. It also works if the process is inverted. It also works with a
                > vimd.exe built with nmake /f Make_ivc.mak cfg="Vim - Win32 Debug vim".
                > I think we have a fix that is worth others trying to break.

                Walter (and all),

                For some reason I had to apply the patch manually (probably
                my mail client trashing the tabs), but I can confirm a
                successful test building with DJGPP version 2.02. :)

                Vince
                Legal Disclaimer: Any views expressed by the sender of this message are
                not necessarily those of Application Solutions Ltd. Information in this
                e-mail may be confidential and is for the use of the intended recipient
                only, no mistake in transmission is intended to waive or compromise such
                privilege. Please advise the sender if you receive this e-mail by mistake.
              • Bram Moolenaar
                ... Using _truename() sounds like a very nice and simple solution. Did you test that it also expand directory names, as in c: longna~1 file and corrects case
                Message 7 of 15 , Apr 2, 2003
                • 0 Attachment
                  Walter Briscoe wrote:

                  > >> >Yes, all this is supposed to be done by mch_FullName(). Somehow it
                  > >> >doesn't work.
                  > >>
                  > >> The two versions of mch_FullName() in os_msdos.c and os_mswin.c give
                  > >> different outputs from the same input. I think the code in os_msdos.c is
                  > >> defective and am working on changing it.
                  > >
                  > >That's probably the right solution.
                  > I am sorry it has taken me a long time to respond on this. I have some
                  > work I am ready to show. It was developed as a stand-alone function and
                  > then integrated into Vim. I looked at djg 2.03 documentation and found a
                  > function which seems to hit the spot: _truename. I have done some
                  > testing with the latest 2.03 build - to avoid the ntvdm.exe problems -
                  > and with 2.04 alpha. I have exercised the code with W2KSP3 and W95. I
                  > dare say it needs more testing; I have not been able to break it as I
                  > easily could with the old code. The code is seriously shorter.

                  Using _truename() sounds like a very nice and simple solution.
                  Did you test that it also expand directory names, as in
                  "c:\longna~1\file" and corrects case differences?

                  > This is a frightening truncation of the code. If Bram (or anybody else)
                  > can point me at a URL for an obsolescent version of DJGPP, I will also
                  > test against that.

                  DJGPP updates come out very slow, I believe 2.02 is from 2000. And it's
                  free, thus updating to a recent version is always possible. Therefore,
                  it's not too important to test with versions earlier than 2.02.

                  > I found difficulties building with the 2.04 alpha.
                  > gcc -c -O2 -DMSDOS -Iproto -Wall -Dinterrupt= -Dfar= -DMAXMEM=512 -D_NAIVE_DOS_REGS misc2.c -o obj/misc2.o
                  > misc2.c: In function `putenv':
                  > misc2.c:5371: argument `string' doesn't match prototype
                  > c:/djgpp/include/stdlib.h:104: prototype declaration
                  > make.exe: *** [obj/misc2.o] Error 1
                  >
                  > C:\wfb\vim\bld\vim61\src> sed 104!d < c:/djgpp/include/stdlib.h
                  > int putenv(char *_val);
                  >
                  > C:\wfb\vim\bld\vim61\src> sed 5368,5371!d < misc2.c
                  > int
                  > putenv(string)
                  > const char *string;
                  > {
                  >
                  > IEEE Std 1003.1-2001 has
                  > #include <stdlib.h>
                  >
                  > int putenv(char *string);
                  >
                  > My first response is to patch misc2.c. I see proto.h also has const. I
                  > will not submit patches for this.

                  There are conflicting standards for putenv(). I rather not change
                  misc2.c, it has already been tested to work on many systems. If DJGPP
                  does have a putenv() function, HAVE_PUTENV should be defined. That's
                  should be in os_msdos.h. But if DJGPP 2.03 doesn't have it, we need a
                  check for DJGPP 2.04. Does it pass the version number somehow?

                  > Fixing mch_FullName() fixes the problem; w .bashrc while editing
                  > bashrc~1 works with a vim.exe built with Make_djg.mak and DJGPP 2.04
                  > alpha. It also works if the process is inverted. It also works with a
                  > vimd.exe built with nmake /f Make_ivc.mak cfg="Vim - Win32 Debug vim".
                  > I think we have a fix that is worth others trying to break.

                  Glad you managed to track it down and come up with a solution that makes
                  the code simpler!

                  --
                  PRINCE: He's come to rescue me, father.
                  LAUNCELOT: (embarrassed) Well, let's not jump to conclusions ...
                  "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 Wed, 2 Apr 2003 23:34:37 in , Bram Moolenaar writes ... Yes! Curiously, there
                  Message 8 of 15 , Apr 2, 2003
                  • 0 Attachment
                    In message <200304022134.h32LYb414982@...> of Wed, 2 Apr 2003
                    23:34:37 in , Bram Moolenaar <Bram@...> writes
                    >
                    >Walter Briscoe wrote:
                    >
                    >> >> >Yes, all this is supposed to be done by mch_FullName(). Somehow it
                    >> >> >doesn't work.
                    >> >>
                    >> >> The two versions of mch_FullName() in os_msdos.c and os_mswin.c give
                    >> >> different outputs from the same input. I think the code in os_msdos.c is
                    >> >> defective and am working on changing it.
                    >> >
                    >> >That's probably the right solution.
                    >> I am sorry it has taken me a long time to respond on this. I have some
                    >> work I am ready to show. It was developed as a stand-alone function and
                    >> then integrated into Vim. I looked at djg 2.03 documentation and found a
                    >> function which seems to hit the spot: _truename. I have done some
                    >> testing with the latest 2.03 build - to avoid the ntvdm.exe problems -
                    >> and with 2.04 alpha. I have exercised the code with W2KSP3 and W95. I
                    >> dare say it needs more testing; I have not been able to break it as I
                    >> easily could with the old code. The code is seriously shorter.
                    >
                    >Using _truename() sounds like a very nice and simple solution.
                    >Did you test that it also expand directory names, as in
                    >"c:\longna~1\file" and corrects case differences?
                    Yes! Curiously, there seems to be case-distinction with device names
                    too. One machine produces c: - another C:. I found no problem in any of
                    this and so did not force C:

                    >
                    >> This is a frightening truncation of the code. If Bram (or anybody else)
                    >> can point me at a URL for an obsolescent version of DJGPP, I will also
                    >> test against that.
                    >
                    >DJGPP updates come out very slow, I believe 2.02 is from 2000. And it's
                    >free, thus updating to a recent version is always possible. Therefore,
                    >it's not too important to test with versions earlier than 2.02.
                    Good!

                    >
                    >> I found difficulties building with the 2.04 alpha.
                    >> gcc -c -O2 -DMSDOS -Iproto -Wall -Dinterrupt= -Dfar= -DMAXMEM=512 -
                    >>D_NAIVE_DOS_REGS misc2.c -o obj/misc2.o
                    >> misc2.c: In function `putenv':
                    >> misc2.c:5371: argument `string' doesn't match prototype
                    >> c:/djgpp/include/stdlib.h:104: prototype declaration
                    >> make.exe: *** [obj/misc2.o] Error 1
                    >>
                    >> C:\wfb\vim\bld\vim61\src> sed 104!d < c:/djgpp/include/stdlib.h
                    >> int putenv(char *_val);
                    >>
                    >> C:\wfb\vim\bld\vim61\src> sed 5368,5371!d < misc2.c
                    >> int
                    >> putenv(string)
                    >> const char *string;
                    >> {
                    >>
                    >> IEEE Std 1003.1-2001 has
                    >> #include <stdlib.h>
                    >>
                    >> int putenv(char *string);
                    >>
                    >> My first response is to patch misc2.c. I see proto.h also has const. I
                    >> will not submit patches for this.
                    >
                    >There are conflicting standards for putenv(). I rather not change
                    >misc2.c, it has already been tested to work on many systems. If DJGPP
                    >does have a putenv() function, HAVE_PUTENV should be defined. That's
                    >should be in os_msdos.h. But if DJGPP 2.03 doesn't have it, we need a
                    >check for DJGPP 2.04. Does it pass the version number somehow?
                    DJGPP does have putenv(). I built without diagnostic in 2.03 and 2.04
                    with the following change:
                    C:\wfb\vim\bld\vim61> diff -c src/0os_msdos.h src/os_msdos.h
                    *** src/0os_msdos.h Sun Aug 5 16:18:34 2001
                    --- src/os_msdos.h Wed Apr 2 23:03:12 2003
                    ***************
                    *** 39,44 ****
                    --- 39,45 ----
                    #endif
                    #define BREAKCHECK_SKIP 1 /* call mch_breakcheck() each time, it's fast */
                    #define HAVE_AVAIL_MEM
                    + #define HAVE_PUTENV

                    /*
                    * Borland C++ 3.1 doesn't have _RTLENTRYF

                    C:\wfb\vim\bld\vim61>

                    Would Bram like the settings of HAVE_* to be checked?

                    >
                    >> Fixing mch_FullName() fixes the problem; w .bashrc while editing
                    >> bashrc~1 works with a vim.exe built with Make_djg.mak and DJGPP 2.04
                    >> alpha. It also works if the process is inverted. It also works with a
                    >> vimd.exe built with nmake /f Make_ivc.mak cfg="Vim - Win32 Debug vim".
                    >> I think we have a fix that is worth others trying to break.
                    >
                    >Glad you managed to track it down and come up with a solution that makes
                    >the code simpler!
                    Me too! I tend to be suspicious of a free lunch.
                    --
                    Walter Briscoe
                  • Bram Moolenaar
                    ... So long as on one machine both c:/file and C:/File are mapped to the exactly the same name, so that comparing the strings tells us if they are
                    Message 9 of 15 , Apr 3, 2003
                    • 0 Attachment
                      Walter Briscoe wrote:

                      > >Using _truename() sounds like a very nice and simple solution.
                      > >Did you test that it also expand directory names, as in
                      > >"c:\longna~1\file" and corrects case differences?
                      > Yes! Curiously, there seems to be case-distinction with device names
                      > too. One machine produces c: - another C:. I found no problem in any of
                      > this and so did not force C:

                      So long as on one machine both "c:/file" and "C:/File" are mapped to the
                      exactly the same name, so that comparing the strings tells us if they
                      are different files or not.

                      > >There are conflicting standards for putenv(). I rather not change
                      > >misc2.c, it has already been tested to work on many systems. If DJGPP
                      > >does have a putenv() function, HAVE_PUTENV should be defined. That's
                      > >should be in os_msdos.h. But if DJGPP 2.03 doesn't have it, we need a
                      > >check for DJGPP 2.04. Does it pass the version number somehow?
                      >
                      > DJGPP does have putenv(). I built without diagnostic in 2.03 and 2.04
                      > with the following change:

                      I vagually recall a problem with putenv(), I'm not sure it was with
                      DJGPP. Can someone try this patch with DJGPP 2.02?

                      > C:\wfb\vim\bld\vim61> diff -c src/0os_msdos.h src/os_msdos.h
                      > *** src/0os_msdos.h Sun Aug 5 16:18:34 2001
                      > --- src/os_msdos.h Wed Apr 2 23:03:12 2003
                      > ***************
                      > *** 39,44 ****
                      > --- 39,45 ----
                      > #endif
                      > #define BREAKCHECK_SKIP 1 /* call mch_breakcheck() each time, it's fast */
                      > #define HAVE_AVAIL_MEM
                      > + #define HAVE_PUTENV
                      >
                      > /*
                      > * Borland C++ 3.1 doesn't have _RTLENTRYF
                      >

                      > Would Bram like the settings of HAVE_* to be checked?

                      What do you mean?

                      --
                      A mathematician is a device for turning coffee into theorems.
                      Paul Erdos
                      A computer programmer is a device for turning coffee into bugs.
                      Bram Moolenaar

                      /// 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, 3 Apr 2003 22:27:35 in , Bram Moolenaar writes ... I can find no differences
                      Message 10 of 15 , Apr 3, 2003
                      • 0 Attachment
                        In message <200304032027.h33KRZL13737@...> of Thu, 3 Apr 2003
                        22:27:35 in , Bram Moolenaar <Bram@...> writes
                        >
                        >Walter Briscoe wrote:
                        >
                        >> >Using _truename() sounds like a very nice and simple solution.
                        >> >Did you test that it also expand directory names, as in
                        >> >"c:\longna~1\file" and corrects case differences?
                        >> Yes! Curiously, there seems to be case-distinction with device names
                        >> too. One machine produces c: - another C:. I found no problem in any of
                        >> this and so did not force C:
                        >
                        >So long as on one machine both "c:/file" and "C:/File" are mapped to the
                        >exactly the same name, so that comparing the strings tells us if they
                        >are different files or not.
                        I can find no differences with one program on one machine. .bashrc
                        .BASHRC bashrc~1 and BASHRC~1 are all mapped to .bashrc. "c:/file"
                        C:\FiLE etc. are all mapped to the same full name. On one W2K machine, I
                        saw C: consistently; on another W95, I saw c: consistently. I saw
                        nothing inconsistent on one machine.

                        >
                        >> >There are conflicting standards for putenv(). I rather not change
                        >> >misc2.c, it has already been tested to work on many systems. If DJGPP
                        >> >does have a putenv() function, HAVE_PUTENV should be defined. That's
                        >> >should be in os_msdos.h. But if DJGPP 2.03 doesn't have it, we need a
                        >> >check for DJGPP 2.04. Does it pass the version number somehow?
                        >>
                        >> DJGPP does have putenv(). I built without diagnostic in 2.03 and 2.04
                        >> with the following change:
                        >
                        >I vagually recall a problem with putenv(), I'm not sure it was with
                        >DJGPP. Can someone try this patch with DJGPP 2.02?
                        Vince confirmed it builds; I don't think he checked it worked.

                        >
                        >> C:\wfb\vim\bld\vim61> diff -c src/0os_msdos.h src/os_msdos.h
                        >> *** src/0os_msdos.h Sun Aug 5 16:18:34 2001
                        >> --- src/os_msdos.h Wed Apr 2 23:03:12 2003
                        >> ***************
                        >> *** 39,44 ****
                        >> --- 39,45 ----
                        >> #endif
                        >> #define BREAKCHECK_SKIP 1 /* call mch_breakcheck() each
                        >>time, it's fast */
                        >> #define HAVE_AVAIL_MEM
                        >> + #define HAVE_PUTENV
                        >>
                        >> /*
                        >> * Borland C++ 3.1 doesn't have _RTLENTRYF
                        >>
                        >
                        >> Would Bram like the settings of HAVE_* to be checked?
                        >
                        >What do you mean?
                        HAVE_* represented the series of names specified in config.h.in
                        For example:
                        ...
                        #undef HAVE_USLEEP
                        #undef HAVE_UTIME
                        #undef HAVE_BIND_TEXTDOMAIN_CODESET

                        /* Define if you do not have utime(), but do have the utimes() function. */
                        #undef HAVE_UTIMES

                        /* Define if you have the header file: */
                        #undef HAVE_DIRENT_H
                        #undef HAVE_ERRNO_H
                        ...

                        In a civilized (UNIX) world, those names are set by a configure script
                        testing each in turn. At least one name (HAVE_PUTENV) was wrongly set in
                        a djgpp environment. I offered to check them all.
                        --
                        Walter Briscoe
                      • Vince Negri
                        ... Seems ok with 2.02 here. Vince Legal Disclaimer: Any views expressed by the sender of this message are not necessarily those of Application Solutions Ltd.
                        Message 11 of 15 , Apr 3, 2003
                        • 0 Attachment
                          > I vagually recall a problem with putenv(), I'm not sure it was with
                          > DJGPP. Can someone try this patch with DJGPP 2.02?
                          >>+ #define HAVE_PUTENV

                          Seems ok with 2.02 here.

                          Vince
                          Legal Disclaimer: Any views expressed by the sender of this message are
                          not necessarily those of Application Solutions Ltd. Information in this
                          e-mail may be confidential and is for the use of the intended recipient
                          only, no mistake in transmission is intended to waive or compromise such
                          privilege. Please advise the sender if you receive this e-mail by mistake.
                        • Vince Negri
                          ... I did, and it did - files edited using the short name did not lose the long name when saved back. Vince Legal Disclaimer: Any views expressed by the sender
                          Message 12 of 15 , Apr 3, 2003
                          • 0 Attachment
                            > >I vagually recall a problem with putenv(), I'm not sure it was with
                            > >DJGPP. Can someone try this patch with DJGPP 2.02?
                            > Vince confirmed it builds; I don't think he checked it worked.

                            I did, and it did - files edited using the short name
                            did not lose the long name when saved back.

                            Vince


                            Legal Disclaimer: Any views expressed by the sender of this message are
                            not necessarily those of Application Solutions Ltd. Information in this
                            e-mail may be confidential and is for the use of the intended recipient
                            only, no mistake in transmission is intended to waive or compromise such
                            privilege. Please advise the sender if you receive this e-mail by mistake.
                          • Walter Briscoe
                            In message of Fri, 4 Apr 2003 08:11:43 in , Vince Negri
                            Message 13 of 15 , Apr 4, 2003
                            • 0 Attachment
                              In message <35C843B8EC93D511844500306E0029B34974FA@...-
                              electronics.co.uk> of Fri, 4 Apr 2003 08:11:43 in , Vince Negri
                              <vnegri@...> writes
                              >> >I vagually recall a problem with putenv(), I'm not sure it was with
                              >> >DJGPP. Can someone try this patch with DJGPP 2.02?
                              >> Vince confirmed it builds; I don't think he checked it worked.
                              >
                              >I did, and it did - files edited using the short name
                              >did not lose the long name when saved back.
                              I think Bram was concerned about the working of putenv() in DJGPP 2.02.
                              I don't suppose you checked that! I'll construct a trivial test to save
                              you doing so:
                              C:\wfb\vim\bld\vim61\src> gcc -O2 -DMSDOS -Iproto -Wall -Dinterrupt= -Dfar= -DMAXMEM=512 -D_NAIVE_DOS_REGS tryenv.c -o tryenv.exe

                              C:\wfb\vim\bld\vim61\src> tryenv fred bill
                              Afore fred was "UnSeT"
                              After fred was "bill"
                              Used putenv("fred=bill")

                              C:\wfb\vim\bld\vim61\src> type tryenv.c
                              /* tryenv.c
                              *
                              * Trivial file to test putenv
                              *
                              * When Who What
                              * 2003-04-04 W.Briscoe Original
                              */
                              #include <stdio.h>
                              #include <stdlib.h>

                              int main(int argc, char ** argv) /* Don't care about incorrect arguments */
                              {
                              char *name = argv[1];
                              char *value = argv[2];
                              char *afore = getenv(name);
                              char *after;
                              static char setting[1024]; /* static for putenv() */

                              sprintf(setting, "%s=%s", name, value);
                              (void)putenv(setting);
                              after = getenv(name);
                              printf("Afore %s was \"%s\"\n", name, (afore) ? afore : "UnSeT");
                              printf("After %s was \"%s\"\n", name, (after) ? after : "UnSeT");
                              printf("Used putenv(\"%s\")\n", setting);
                              return 0;
                              }

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

                              By the way:
                              1) Can Vince use References: headers to allow thread link construction?
                              2) Bram, I went into an infinite loop again with make -f Make_djg.mak -n
                              as I attempted to grab a line to compile the new source. It took a fair
                              number of Cytl+C hits to kill the make. The "infinite" loop stops when
                              the machine runs out of virtual memory. It then sorts itself. I had not
                              rolled forward my --directory patch. I have still to acquire an
                              understanding of the internals of make. I did find a bug in the VC make
                              for it. :-) I suppose I ought to have a "pending" patches folder to deal
                              with such situations. It should reduce the incidence of inadvertently
                              destroyed work!! I am not ready to go for full source control.
                              --
                              Walter Briscoe
                            • Vince Negri
                              ... Thanks for the program. Seems to be fine: c: vim6 src tryenv fred bill Afore fred was UnSeT After fred was bill Used putenv( fred=bill ) ... I m stuck
                              Message 14 of 15 , Apr 4, 2003
                              • 0 Attachment
                                > I don't suppose you checked that! I'll construct a trivial test to save
                                > you doing so:

                                Thanks for the program. Seems to be fine:

                                c:\vim6\src>tryenv fred bill
                                Afore fred was "UnSeT"
                                After fred was "bill"
                                Used putenv("fred=bill")


                                > By the way:
                                > 1) Can Vince use References: headers to allow thread link construction?

                                I'm stuck with MS Outlook 97, sorry - by order of the boss :-/

                                Vince


                                Legal Disclaimer: Any views expressed by the sender of this message are
                                not necessarily those of Application Solutions Ltd. Information in this
                                e-mail may be confidential and is for the use of the intended recipient
                                only, no mistake in transmission is intended to waive or compromise such
                                privilege. Please advise the sender if you receive this e-mail by mistake.
                              • Bram Moolenaar
                                ... You could check them, but since Vim currently compiles fine, I would be surprised if the list is really wrong. Careful: DJGPP may implement some things in
                                Message 15 of 15 , Apr 4, 2003
                                • 0 Attachment
                                  Walter Briscoe wrote:

                                  > >> Would Bram like the settings of HAVE_* to be checked?
                                  > >
                                  > >What do you mean?
                                  >
                                  > HAVE_* represented the series of names specified in config.h.in
                                  > For example:
                                  > ...
                                  > #undef HAVE_USLEEP
                                  > #undef HAVE_UTIME
                                  > #undef HAVE_BIND_TEXTDOMAIN_CODESET
                                  >
                                  > /* Define if you do not have utime(), but do have the utimes() function. */
                                  > #undef HAVE_UTIMES
                                  >
                                  > /* Define if you have the header file: */
                                  > #undef HAVE_DIRENT_H
                                  > #undef HAVE_ERRNO_H
                                  > ...
                                  >
                                  > In a civilized (UNIX) world, those names are set by a configure script
                                  > testing each in turn. At least one name (HAVE_PUTENV) was wrongly set in
                                  > a djgpp environment. I offered to check them all.

                                  You could check them, but since Vim currently compiles fine, I would be
                                  surprised if the list is really wrong. Careful: DJGPP may implement
                                  some things in a way it doesn't work 100% for Vim and Vim must use its
                                  internal function anyway.

                                  --
                                  Q: How many hardware engineers does it take to change a lightbulb?
                                  A: None. We'll fix it in software.

                                  /// 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.