sv@v7fs1.UUCP (Steve Verity) (03/10/90)
I want to have a path that is almost 150 characters long. Unfortunately, DOS truncates the path I specify in my autoexec, if it gets too long. There must be a work around, no? -- ...........>..........>........>......>...>...>..>..>..>..>.>.>.>>>>>>>>+ . Steve Verity sv@v7fs1 + + Now where did I leave my D50? + . Video-7 / Headland Technology + ...ames!vsi1!v7fs1!sv + .. +
bmp@hpcupt1.HP.COM (Brian M. Perkin) (03/10/90)
Have more than one path statement, where the second statement references the first as %%PATH%%%PATH% .
ear@wpi.wpi.edu (Eric A Rasmussen) (03/10/90)
In article <1941@v7fs1.UUCP> sv@v7fs1.UUCP (Steve Verity) writes: >I want to have a path that is almost 150 characters long. Unfortunately, >DOS truncates the path I specify in my autoexec, if it gets too long. >There must be a work around, no? The problem is that your environment size is not large enough. In order to increase it, you need to use the COMMAND command in your autoexec.bat file. For the proper syntax, look in your dos manual. Also, look at the replies on how to make Microsoft Word look elsewhere for command.com. Many of them suggest using the COMMAND command and give examples of how to use it properly. _ _ +-=-=-=-=-=-=-=-=-+ |_ ,_ . _ |_} _ _ ,_ _ _ _ _ ,_ | ear@wpi.wpi.edu | |_ | | |_ | \ |_\ _> | | | |_| _> _> |_' | | | ear%wpi@wpi.edu | --< A real engineer never reads the instructions first! >-- +-=-=-=-=-=-=-=-=-+
stever@Octopus.COM (Steve Resnick ) (03/11/90)
In article <1941@v7fs1.UUCP> sv@v7fs1.UUCP (Steve Verity) writes: > >I want to have a path that is almost 150 characters long. Unfortunately, >DOS truncates the path I specify in my autoexec, if it gets too long. > >There must be a work around, no? > Yes! There is. The environment used by DOS is a function of the shell, COMMAND.COM There is a switch for command.com /E:<n> where n specifies the environment size. This can be up to 32767 bytes in length. To do this at boot up put the line SHELL=C:\COMMAND.COM /E:1024 /P The /P is needed to make the fisrt copy of command "permenant" and force it to load autoexec.bat. Since the default environment size is 128 bytes your path exceeds that limit.... Steve
rossp@quiche.cs.mcgill.ca (Ross PORTER) (03/11/90)
In article <1941@v7fs1.UUCP> sv@v7fs1.UUCP (Steve Verity) writes: > >I want to have a path that is almost 150 characters long. Unfortunately, >DOS truncates the path I specify in my autoexec, if it gets too long. > >There must be a work around, no? > > Yes, Steve, there is a work-around. The problem is that DOS only allows 128 chars on the commmand line. The solution is to abbreviate individual paths so that a large number can fit in 128 chars. Suppose, for brevity's sake, that you want to include only two individual paths in the PATH environment variable: subst f: c:\program\dos subst g: c:\program\win386 path=f:;g:; You have to tell DOS to allocate space for these "device handles" (f,g), by including lastdrive=[letter] e.g. lastdrive=z in config.sys. Note that 26 (a-z) drive handles is all you get. This is something of a bastardization of the SUBST command. IBM/Microsoft introduced SUBST with hard drives. It was designed to fool older applications that were not hard disk aware. So, if your copy of PeachTree G/L looked for data on drive B:, DOS could fool it into looking in a particular directory on the hard drive instead: subst b: c:\data\peach Ross Porter rossp@calvin.cs.mcgill.ca
consp21@bingsunl.cc.binghamton.edu (Ken Hoover) (03/11/90)
In article <1990Mar10.165143.20886@Octopus.COM>, stever@Octopus.COM (Steve Resnick ) writes: > >I want to have a path that is almost 150 characters long. Unfortunately, >DOS truncates the path I specify in my autoexec, if it gets too long. > >There must be a work around, no? > DOS has a 60-character limit on paths, if I remember correctly. Keep in mind that when you specify a path, the computer will search through ALL of the directories you specify (in order) to look for a command (filename) that you type. a 150-character path is IMMENSE! Your system response time will be lousy. A better idea than increasing the length of the path string is to put just three or four directories in your path (your misc. utilities directory, your DOS stuff, your root dir if necessary, and a directory full of batch files for all the other programs that you use and would want in your path. If, for instancs, you have WordPerfect in a directory called C:\WP50, then you can make a batch file called WP.BAT that contains the two lines: cd \wp50 wp %1 And stick it in your batch file directory. That way, you type WP, it looks through two or three dirs (instead of 15 or 16) finds the batch file, and off you go into WP. If your batch file directory is the first one in the path, you only have to look in one dir to hit the batch file, and your system response time disappears. If you do this for all of your programs that require that their directory be in the path, you'll make your life a lot easier. If you have any questions about batch file language look in your DOS manual or write me directly and I'll assist as best I can. - Ken ------------------------------------------------------------------------------ Ken Hoover [ consp21@bingsuns.pod.binghamton.edu | consp21@bingvaxa.BITNET ] Senior undergraduate consultant, SUNY-Binghamton Computer Center ------------------------------------------------------------------------------
ear@wpi.wpi.edu (Eric A Rasmussen) (03/11/90)
In article <3124@bingvaxu.cc.binghamton.edu> consp21@bingsunl.cc.binghamton.edu (Ken Hoover) writes: > DOS has a 60-character limit on paths, if I remember correctly. While you are basically correct, I think you misunderstood the poster's problem. There have already been quite a few suggestions posted publically on how to fix the problem so I will not bother restating any here, but your explanation does raise an interesting point. From what I have experienced, you can actually have a single path be longer than 60 characters, but you can only access it manually from the dos prompt or through a batch file. The problem is that almost no known software can access a file or directory who's path is longer than 60 characters. I think Norton's Change Directory utility might have been able to do it, but I'm not positive. This brings me to my question for any MS-DOS gurus out there. How can you access paths longer than 60 characters from a piece of software? A friend of mine, who is a genius at this type of stuff, was unable to figure it out. From what I understood, the machine would hang when a DOS call was made that tried to access a path longer than 60 characters. (He was using Turbo-C 2.0) _ _ +-=-=-=-=-=-=-=-=-+ |_ ,_ . _ |_} _ _ ,_ _ _ _ _ ,_ | ear@wpi.wpi.edu | |_ | | |_ | \ |_\ _> | | | |_| _> _> |_' | | | ear%wpi@wpi.edu | --< A real engineer never reads the instructions first! >-- +-=-=-=-=-=-=-=-=-+
bmp@hpcupt1.HP.COM (Brian M. Perkin) (03/15/90)
I earlier wrote: # / hpcupt1:comp.sys.ibm.pc.programmer / bmp@hpcupt1.HP.COM (Brian M. Perkin) / 7:12 pm Mar 9, 1990 / # Have more than one path statement, where # the second statement references the first as %%PATH%%%PATH% . It appears ( from the polite and other messages I received) that I was STTY'ed wrong when I typed this. The variable used to expand the previous definition of the path string should be %PATH%. For example Set path=c:\;c:\bin and Set path=%path%;c:\etc will expand as you would expect. (Dos documentation treats the Path command and set path= as synonomous.) There may be a limit on the size of individual strings, I don't know that. The overall size of the string table is configurable with the /E: parameter when you load COMMAND.COM (often done in the SHELL statement in Config.Sys. Sorry for confusion. Brian
d88-cwe@nada.kth.se (Christian Wettergren) (03/19/90)
In article <1941@v7fs1.UUCP> sv@v7fs1.UUCP (Steve Verity) writes: >I want to have a path that is almost 150 characters long. Unfortunately, >DOS truncates the path I specify in my autoexec, if it gets too long. >There must be a work around, no? Beware, though! MSDOS 3.2 will hang itself in a strange way if your commandline exceeds eigthy chars. If it is exactly eigthy chars, command.com will behave strange, outputting %d, %s etc until you press Ctrl-C. This can't be cirumvented without a program. I discovered this while I was writing a batch-utility that saved parts of paths in batch-files and then recalled them to the path. I had to give upp this project because of this limitation. (Yes, a batch-file that outputted another batch-file.) Regards, Christian Wettergren -- -------------------------------------------------------------------------- "Computer Science is not about computers, any more than astronomy is about telescopes" - Edgar Dijkstra Christian Wettergren, d88-cwe@nada.kth.se, 08 - 36 96 92
d88-cwe@nada.kth.se (Christian Wettergren) (03/19/90)
In article <9575@wpi.wpi.edu> ear@wpi.wpi.edu (Eric A Rasmussen) writes: >In article <3124@bingvaxu.cc.binghamton.edu> consp21@bingsunl.cc.binghamton.edu (Ken Hoover) writes: > >> DOS has a 60-character limit on paths, if I remember correctly. > >While you are basically correct, I think you misunderstood the poster's >problem. There have already been quite a few suggestions posted publically on >how to fix the problem so I will not bother restating any here, but your >explanation does raise an interesting point. What are we talking about here ? Is it a problem with the size of the command-line, more specific while you enter the PATH-variable in the environment. Or is it a problem with dos limitation of paths, that is directories and subdirectories etc, to 64 chars ? The latter I think you can't cirumvents in any way short of rewriting MSDOS (MS-UNIX ? ;-)). The first alternative is not impossible though! All you have to do is to look up the environment in memory, makes sure it is the master-environment, and patch it by hand, or better, by program! Regards, Christian Wettergren -- -------------------------------------------------------------------------- "Computer Science is not about computers, any more than astronomy is about telescopes" - Edgar Dijkstra Christian Wettergren, d88-cwe@nada.kth.se, 08 - 36 96 92
feg@clyde.ATT.COM (Forrest Gehrke,2C-119,7239,ATTBL) (03/19/90)
In article <9569@wpi.wpi.edu>, ear@wpi.wpi.edu (Eric A Rasmussen) writes: > In article <1941@v7fs1.UUCP> sv@v7fs1.UUCP (Steve Verity) writes: > >I want to have a path that is almost 150 characters long. Unfortunately, > >DOS truncates the path I specify in my autoexec, if it gets too long. > > The problem is that your environment size is not large enough. In order to I think the original poster was asking how to set a path longer than DOS limit of 127 characters, not how to increase his environment. The problem encountered (even when the environment is large enough to accept a longer path statement) is that msdos will not accept an attempt to type a line longer than 127 characters. There is a workaround to be found in SIMTEL20 in the SYSUTL directory. A program simply called BIGPATH. I found it to work ok. Another route is a program called EE2 which I obtained from a BBS. This one allows a temporary modification of anything in the environment (provided it is big enough), good for the current session only. I don't know if this program is available on SIMTEL20 but I wouldn't be surprised if it is. Forrest Gehrke feg@clyde.ATT.COM
rothstein@nutmeg.Enet.DEC.com (Lee Rothstein, 603-884-0039) (03/20/90)
In article <100010002@hpcupt1.HP.COM>, bmp@hpcupt1.HP.COM (Brian M. Perkin) writes... >I earlier wrote: > ># / hpcupt1:comp.sys.ibm.pc.programmer / bmp@hpcupt1.HP.COM (Brian M. Perkin) / 7:12 pm Mar 9, 1990 / ># Have more than one path statement, where ># the second statement references the first as %%PATH%%%PATH% . > >It appears ( from the polite and other messages I received) >that I was STTY'ed wrong when I typed this. > >The variable used to expand the previous definition of the >path string should be %PATH%. > >For example > >Set path=c:\;c:\bin >and >Set path=%path%;c:\etc > >will expand as you would expect. >(Dos documentation treats the Path command and set path= as synonomous.) This has been proposed many times. It does not work on any version of DOS, on any 80x86 hardware I have ever seen!! Why? Because the expansion of the environment variable on the right side of the assign is done before it is submitted to command.com and therfore the 128 character truncation of the command line still occurs. For versions of DOS before 3.3, enved by Scott Robert Ladd can be used from a batch file to set a path <= 256 characters. Enved does not work with DOS 3.3, at least for the versions with which I'm familiar. Can we please not propigate the same wrong answers ad nauseum? Thanks! +---------------------------------------------------------+ | Lee Rothstein * UUCP: {purdue,ucbvax,hplabs,labrea,sun, | | pyramid,gryphon,angelo}!decwrl!nutmeg.dec.com!rothstein| | * Arpa/Domain Address: rothstein@nutmeg.enet.dec.com | +---------------------------------------------------------+
jlg@lambda.UUCP (Jim Giles) (03/20/90)
From article <9393@shlump.nac.dec.com>, by rothstein@nutmeg.Enet.DEC.com (Lee Rothstein, 603-884-0039): > [...] > Can we please not propigate the same wrong answers ad nauseum? Why should this newsgroup be any different from all the others? J. Giles
reeves@dvinci.usask.ca (Malcolm Reeves) (03/20/90)
From article <9575@wpi.wpi.edu>, by ear@wpi.wpi.edu (Eric A Rasmussen): > In article <3124@bingvaxu.cc.binghamton.edu> consp21@bingsunl.cc.binghamton.edu (Ken Hoover) writes: > >> DOS has a 60-character limit on paths, if I remember correctly. > I thought that DOS would accept 126 chars on the command line and that the 60-char limit was typical of the space allocated for path strings by applications software? I know you can't fool DOS with substitutions for %1 etc in batch files. It would be interesting to know the exact limits - I might experiment a little to find out....... if no one comes up with a definitive answer first.
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (03/21/90)
In article <9393@shlump.nac.dec.com> rothstein@nutmeg.Enet.DEC.com (Lee Rothstein, 603-884-0039) writes:
$>For example
$>Set path=c:\;c:\bin
$>and
$>Set path=%path%;c:\etc
$>will expand as you would expect.
$>(Dos documentation treats the Path command and set path= as synonomous.)
$This has been proposed many times. It does not work on any
$version of DOS, on any 80x86 hardware I have ever seen!!
It won't expand beyond 128 characters; however, for shorter strings, it
does work.
$Because the expansion of the environment variable on the right side
$of the assign is done before it is submitted to command.com and
$therfore the 128 character truncation of the command line still
$occurs.
Wrong. The expansion of environment variables (which, BTW, only works
in batch files) _is_ done by COMMAND.COM. The only part of command input
and processing which is not done by COMMAND.COM is the actual input and
editing of the line (this is done with a DOS call).
I would imagine that since the input is limited in length to 128
(or maybe 127 ... I'm not sure) bytes, COMMAND.COM assumes that it will
never have to face a command line longer than that, even though using
environment variable expansion can easily generate one several times
that length.
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
"So sorry, I never meant to break your heart ... but you broke mine."