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

Re: Another 9 in todo.txt

Expand Messages
  • Walter Briscoe
    In message of Fri, 28 Mar 2003 20:31:06 in , Bram Moolenaar writes ... I am sorry it has taken
    Message 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.