home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!rutgers!njitgw.njit.edu!hertz.njit.edu!dic5340
- From: dic5340@hertz.njit.edu (David Charlap)
- Newsgroups: comp.os.os2.misc
- Subject: Re: Question Concerning PATH Variable
- Message-ID: <1992Aug17.182057.27253@njitgw.njit.edu>
- Date: 17 Aug 92 18:20:57 GMT
- References: <1992Aug12.180735.22655@intelhf.hf.intel.com> <713751498snx@tgm.CAM.ORG>
- Sender: news@njit.edu
- Organization: New Jersey Institute of Technology, Newark, N.J.
- Lines: 26
- Nntp-Posting-Host: hertz.njit.edu
-
- In article <713751498snx@tgm.CAM.ORG> eric@tgm.CAM.ORG (Eric Trepanier) writes:
- >That's a common DOS limitations, though the limit is 127, not 80. Some
- >people on this newsgroup have claimed that the 127 character limitation
- >was with the length of command lines, not with the actual environment
- >variables. I don't think so, i.e. the following trick does _not_ work:
- >
- >SET PATH=C:\;....(127 character path)...
- >SET PATH=%PATH%;......
-
- That's because the %PATH% variable is expanded into it's full (127
- character) length before use. It's the same old input-buffer limit.
-
- >I know of some PD programs that allow to fool DOS into accepting longer
- >path names, but this does not work with all DOS applications.
-
- They successfully increase the PATH size. It fails with apps because
- the apps use a static 128-byte buffer to hold the path, and a longer
- one overflows the buffer. Kind of stupid, if you ask me.
-
-
-
- --
- |) David Charlap "I don't even represent myself
- /|_ dic5340@hertz.njit.edu sometimes so NJIT is right out!.
- ((|,)
- ~|~ Hi! I am a .signature virus, copy me into your .signature file.
-