heath@ncrcae.Columbia.NCR.COM (Robert Heath) (02/28/90)
How can I set my dos PATH variable longer than 128 bytes? I'm running DOS 3.3. It seems when I set my PATH variable in my AUTOEXEC.BAT, DOS truncates anything longer than 128 bytes. Is there a way to do this by assigning shorter environment variables and concatenating them somehow ? Thanks. Robert Heath
"Arnold G. Gill" <GILLA@QUCDN.QueensU.CA> (02/28/90)
In article <5762@ncrcae.Columbia.NCR.COM>, heath@ncrcae.Columbia.NCR.COM (Robert Heath) says: > >How can I set my dos PATH variable longer than 128 bytes? I'm running >DOS 3.3. It seems when I set my PATH variable in my AUTOEXEC.BAT, >DOS truncates anything longer than 128 bytes. Is there a way to do >this by assigning shorter environment variables and concatenating >them somehow ? Thanks. > > Robert Heath Concatenating variables will *NOT* work at all - the problem is the DOS limit itself. DOS does not allow you to enter environment variables that are longer than 128 characters through DOS. So you circumvent DOS by writing directly to the environment space. This is done by an excellent set of path utilities that are available on SIMTEL20. Unforunately, I cannot remember the name of the file or the author. However, if you wish them, send me a note and I will send you the uu/xxencoded .ZIP or .ARC file (tell me which combination you can handle) of the entire set. These utilities allow you to have a path as long as you need (provided your environment space is large enough), add or delete a particular path from your path list, etc. For anyone with a hard disk system, this is a set of utilities you should have. Simplicity is the order of the day here. ------- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Arnold Gill | | | Queen's University at Kingston | If I hadn't wanted it to be heard | | BITNET : gilla@qucdn | I wouldn't have said it. | | X-400 : Arnold.Gill@QueensU.CA | | | INTERNET : gilla@qucdn.queensu.ca | | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
piety@hplred.HP.COM (Bob Piety) (03/01/90)
Robert, I wish I knew the answer to this problem myself. If you find out, please let me know. My solution around this problem was to rename my directories, using short names, so I could get everything I needed to fit into the 128 char limit. Also, I broke up the paths into several batch files, each for a specific purpose. For example, cdev.bat sets up only the paths & environmental variables necessary for C-code development. I know the above is a hack, but it *does* get around the limit problem. Bob
sadow@ncsatl.uucp (Scott C. Sadow) (03/01/90)
In article <5762@ncrcae.Columbia.NCR.COM>, heath@ncrcae.Columbia.NCR.COM (Robert Heath) writes: > How can I set my dos PATH variable longer than 128 bytes? I'm running > DOS 3.3. It seems when I set my PATH variable in my AUTOEXEC.BAT, > DOS truncates anything longer than 128 bytes. Is there a way to do > this by assigning shorter environment variables and concatenating > them somehow ? Thanks. > > Robert Heath The problem is you are running out of environment space. Check your DOS manual for the correct syntax, but you need the following in you CONFIG.SYS: (I am typing this in from memory) shell=c:command.com /e:256 /p -- Scott Sadow ...gatech!ncsatl!sadow
leonard@bucket.UUCP (Leonard Erickson) (03/02/90)
heath@ncrcae.Columbia.NCR.COM (Robert Heath) writes: >How can I set my dos PATH variable longer than 128 bytes? I'm running >DOS 3.3. It seems when I set my PATH variable in my AUTOEXEC.BAT, >DOS truncates anything longer than 128 bytes. Is there a way to do >this by assigning shorter environment variables and concatenating >them somehow ? Thanks. You can't. DOS has an internal buffer somewhere that is only 128 bytes long. Even if you stuffed something longer into the PATH variable somehow, it'd get truncated when DOS used it. This is a built-in limitation of MS-DOS/PC-DOS. You'll have to live with it. -- Leonard Erickson ...!tektronix!reed!percival!bucket!leonard CIS: [70465,203] "I'm all in favor of keeping dangerous weapons out of the hands of fools. Let's start with typewriters." -- Solomon Short
svirsky@ttidca.TTI.COM (Bill Svirsky) (03/03/90)
In article <90059.112138GILLA@QUCDN.BITNET> GILLA@QUCDN.QueensU.CA (Arnold G. Gill) writes:
+In article <5762@ncrcae.Columbia.NCR.COM>, heath@ncrcae.Columbia.NCR.COM (Robert
+Heath) says:
+>
+>How can I set my dos PATH variable longer than 128 bytes? I'm running
+>DOS 3.3. It seems when I set my PATH variable in my AUTOEXEC.BAT,
+>DOS truncates anything longer than 128 bytes. Is there a way to do
+>this by assigning shorter environment variables and concatenating
+>them somehow ? Thanks.
+>
+> Robert Heath
+
+ Concatenating variables will *NOT* work at all ...
On my Compaq 386 running DOS 3.31 and an IBM PC/AT running PCDOS 3.10 I
have no problem concatenating environment variables *within batch
files*. You can't do it from the command line though. Try the following
in your autoexec.bat:
set path=whatever_the_first_part_of_your_path_is
set path=%path%;whatever_the_next_part_of_your_path_is
...
Just don't make any single "set" command longer than 128 (see below).
+...the problem is the DOS
+limit itself. DOS does not allow you to enter environment variables that are
+longer than 128 characters through DOS. ...
The problem is that MSDOS will not allow a command line over 128 characters
in length.
--
Bill Svirsky, Citicorp+TTI, 3100 Ocean Park Blvd., Santa Monica, CA 90405
Work phone: 213-450-9111 x2597
svirsky@ttidca.tti.com | ...!{csun,psivax,rdlvax,retix}!ttidca!svirskyjdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (03/05/90)
In article <31300010@inmet> gjs@inmet.inmet.com writes: >One method is to use SUBST to assign some of the directories in your >path to "virtual drives," then include the drives in your path. For >example: > subst E: C:\utility\word > subst F: C:\utility\database > subst G: C:\utility\sprdsht > subst H: C:\utility\comm > > path C:\bin;E:;F:;G:;H: This method works, but it seems like a lot of effort. In order to be able to handle lots of different packages on your system without having a path that is too long, I suggest the following: 1. Don't nest your directories. Use a separate directory off the root for each main package of software. This makes it easy to type directory names and keeps them shorter in the path. 2. Use short directory names for directories that will be in your path. E.g. use NORT for Norton Utilities. This allows getting quite a few directory names in your path. 3. Create a \BAT directory to hold batch files for starting up your main software packages, and write a .bat for each package. Put the \BAT directory in the path. This way the main packages do not need to be in the path. 4. Put in your path only those directories that contain collections of programs, such as \DOS, \UTIL, \BAT, \NORT, \BIN, etc. -- John Dudeck "You want to read the code closely..." jdudeck@Polyslo.CalPoly.Edu -- C. Staley, in OS course, teaching ESL: 62013975 Tel: 805-545-9549 Tanenbaum's MINIX operating system.
nraoaoc@nmtsun.nmt.edu (Daniel Briggs) (03/05/90)
In article <25f1ea76.25da@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > [Many suggestions on how to deal with only 128 bytes of PATH space] Here's one more. Use a RAM resident program such as CED to do alias expansion. If a directory has only a couple of executable programs in it, (such as source files plus an executable, or executable plus data files), define aliases to these executables, and don't put the directories in the path at all. You might be surprised to find how many directories fall into this category. ----- This is a shared guest account, please send replies to dbriggs@nrao.edu (Internet) Dan Briggs / NRAO / P.O. Box O / Socorro, NM / 87801 (U.S. Snail)
harper@convex.com (David Harper) (03/05/90)
In article <5762@ncrcae.Columbia.NCR.COM> heath@ncrcae.Columbia.NCR.COM (Robert Heath) writes: >How can I set my dos PATH variable longer than 128 bytes? I'm running >DOS 3.3. It seems when I set my PATH variable in my AUTOEXEC.BAT, >DOS truncates anything longer than 128 bytes. I have been using BIGPATH for several months with no problems. If you install this program in your AUTOEXEC.BAT file it will allow you to (I think) double your path length. It is available through simtel20 in the SYSUTL directory. Dave Harper - Convex Computer Corp. E-mail address: 3000 Waterview Pky. Richardson, TX 75081 harper@convex.COM (214) 497-4525 (W) (214) 727-4206 (H)
mlord@bnr-rsc.UUCP (Mark Lord) (03/07/90)
<In article <5762@ncrcae.Columbia.NCR.COM>, heath@ncrcae.Columbia.NCR.COM (Robert Heath) says: < <How can I set my dos PATH variable longer than 128 bytes? I'm running <DOS 3.3. It seems when I set my PATH variable in my AUTOEXEC.BAT, <DOS truncates anything longer than 128 bytes. Is there a way to do <this by assigning shorter environment variables and concatenating <them somehow ? Thanks. You need APPENV21.ARC from simtel20. I use it to set my own 500 byte PATH. If you cannot figure out how to get it from simtel, email me and I'll send you a copyut (I am the author). Cheers -- ______Mark S. Lord______________________ ______________________________ | ..uunet!bnrgate!carrsc!mlord | These are only MY opinions. | | or: bnr-rsc!mlord@bnrgate | I charge for official views. | |________________________________________|______________________________|
hchen@silver.ucs.indiana.edu (H. Chen) (03/08/90)
In article <25f1ea76.25da@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >1. Don't nest your directories. Use a separate directory off the root >for each main package of software. This makes it easy to type directory >names and keeps them shorter in the path. The other way to get around this problem is to "nest" your directories properly. That is, put your subdirectory for data files under your program's subdirectory, for instance, \rbase all your rbase programs go here \rbase\app1 all your application #1 files using rbase go here \rbase\app2 all your application #2 files using rbase go here \lotus all your lotus programs go here \lotus\pro1 all your project #1 files using lotus go here... ...... Now, put "..\" in your path statement. You don't need "c:\rbase;c:\lotus" anymore. It will eliminate the length of path statement and enhance the program file search speed. You may set up some batch file to bring you into different application subdirectories. Causion, this does apply to DOS or whatever utilities which you want to call from anywhere. che (p.s. I read this from PC Magzine or other pc magzine. Since nobody mention this so far, I put here according to my memory.)
jcb2647@cec1.wustl.edu (James Christopher Beard) (03/08/90)
Sorry I can't help with the original problem, but I would like to suggest that you set things up so that an extremely long path is not needed. How about using batch files (as noted by Bob Piety) to add special-purpose directories to the path only when they are needed, then remove them automatically? There are some directories that really should be on the path all the time, and others that are useless except when you are running a particular application. By way of example, my AUTOEXEC.BAT includes the following: PATH=C:\BAT;C:\UTIL;C:\DOS SET REGPATH=%PATH% (Note that this will not work with DOS 3.0, which mishandles the variable substitution that makes "%PATH%" be understood as "C:\BAT;C:\UTIL;C:\DOS" in the above example. It works fine with 3.1 and later.) MS Word, for example, is invoked with a batch file (located in C:\BAT) that includes the lines PATH=C:\WORD;%PATH% . . .set up other stuff. . . WORD %1 %2 %3 . . . PATH=%REGPATH% The last command restores the path to the "general purpose" version that was stored in the environment variable REGPATH by AUTOEXEC.BAT. Why not have an enormous path that includes the home directory of every application on the hard disk, the way the documentation and/or installation program for so many applications recommend? For one thing, it is a substantial waste of time. Every time you invoke a program not in the current directory, the computer may search through a whole bunch of directories that contain only special-purpose programs. If you're running QuickC, and C:\DEVEL\QC2 is the 10th directory in the path, you unnecessarily search through 9 directories every time you invoke one of QC's executables with the default directory set to something other than C:\DEVEL\QC2. And every time you mistype a command name, practically the whole dang disc is searched before you see "Bad command or file name". For another thing, it wastes environment space and may exceed a hard limit on the path length (but you already know about that). (On the subject of environment space, you may well be aware already that you can have as much space as you like by putting an appropriate SHELL command in CONFIG.SYS: SHELL=C:\DOS\COMMAND.COM /P /E:nnn If you're using DOS 3.2 or later, nnn is the number of bytes to set aside for the environment. For DOS 3.1, nnn is the number of 16-byte "paragraphs" to set aside for the environment.) If your path is of horrible length for some reason other than trying to keep every known executable available at once, you can shorten the number of characters in the path by giving some of the directories "aliases" using the SUBST command a la SUBST E: C:\PROGRAMS\JOE\WORDPROC\WP Then you can include the virtual drive E: in your path. Two notes, though: 1) SUBST mustn't be used in a networked environment, which seems like the place you're most likely to need it, and 2) for the above to work, you need a command of the form "LASTDRIVE=E" in CONFIG.SYS, where you replace "E" with the name of the highest-lettered drive or virtual drive you will ever want to refer to.
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (03/08/90)
In article <1990Mar8.021622.13121@cec1.wustl.edu> jcb2647@cec1.wustl.edu (James Christopher Beard) writes: > >If your path is of horrible length for some reason other than trying >to keep every known executable available at once, you can shorten the >number of characters in the path by giving some of the directories >"aliases" using the SUBST command a la > > SUBST E: C:\PROGRAMS\JOE\WORDPROC\WP > >Then you can include the virtual drive E: in your path. Two notes, >though: 1) SUBST mustn't be used in a networked environment, which >seems like the place you're most likely to need it, and 2) for the >above to work, you need a command of the form "LASTDRIVE=E" in >CONFIG.SYS, where you replace "E" with the name of the >highest-lettered drive or virtual drive you will ever want to refer >to. Just out of interest: what goes wrong in a networked environment? I've been running for years (non-networked) with SUBST E: C:\ in my autoexec; it makes it easy to maintain two views of the same disk, since I can CD independently on C: and E:. What's going to go wrong if I ever hook up to a network? Duncan Murdoch
jcb2647@cec1.wustl.edu (James Christopher Beard) (03/09/90)
In article <1684@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) quotes from my followup: >>. . . you can shorten the >>number of characters in the path by giving some of the directories >>"aliases" using the SUBST command a la >> >> SUBST E: C:\PROGRAMS\JOE\WORDPROC\WP >> >>Then you can include the virtual drive E: in your path. Two notes, >>though: 1) SUBST mustn't be used in a networked environment, which >>seems like the place you're most likely to need it, and 2) for the >>above to work, you need a command of the form "LASTDRIVE=E" in >>CONFIG.SYS, where you replace "E" with the name of the >>highest-lettered drive or virtual drive you will ever want to refer >>to. and then asks: >Just out of interest: what goes wrong in a networked environment? I've >been running for years (non-networked) with > SUBST E: C:\ >in my autoexec; it makes it easy to maintain two views of the same disk, >since I can CD independently on C: and E:. What's going to go wrong >if I ever hook up to a network? I don't know why Microsoft says not to use SUBST when hooked to a network. My caveat comes simply from the MS-DOS manual. I suspect that it has to do with potential wrangling between SUBST and the network software over who gets to apply what alias to what directory where, but a real answer will have to come from someone else.
rjc@atom.OZ (Robert Cawley) (03/09/90)
In article <25f1ea76.25da@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > >In article <31300010@inmet> gjs@inmet.inmet.com writes: >>One method is to use SUBST to assign some of the directories in your >>path to "virtual drives," then include the drives in your path. For >>example: >> subst E: C:\utility\word >> subst F: C:\utility\database >> subst G: C:\utility\sprdsht >> subst H: C:\utility\comm >> >> path C:\bin;E:;F:;G:;H: I missed the start of all this, but here is a program I wrote some years ago to enable me to have a path of any size (up to the size reserved in the environment by SHELL = command.com /p /e=xxx in config.sys, where xxx is the environment size. The program checks for either COMSPEC=, or PATH= as the first entry in the master environment table. This could probably be deleted, but as I only use this in my AUTOEXEC.BAT I have not bothered to do so. Usage is: in autoexec.bat PATH=c:\;c:\bin PATHEX c:\usr\bin;c:\ms\c5 PATHEX d:\zortech\bin each PATHEX line adds the listed directories to the path. I have used this little program for over 5 years without problems. It has been tested with MSDOS 3.3 and 3.2, PCDOS 4.0, 3.3, 3.2, 3.1, 2.1 and 2.0 and seems to have no problems with these. This is compiled with Microsoft C. #include <dos.h> #include <malloc.h> #define PARA 0x10000l char tststr[] = "COMSPEC="; char tststr2[] = "PATH="; int dos33 = 0; int mycmp(a, b, len) char huge *a; char *b; int len; { int i; for (i = 0; i < len; i++) if ( *a++ != *b++ ) return(1); return(0); } char huge *findmast(el) int *el; { unsigned char huge *p = (unsigned char huge *) 0l; unsigned char huge *q; unsigned int owner = 0; unsigned int priown = 0; int len; int i; int first = 0; while (1) { while (*p != 'M') (long int) p += PARA; (long int) q = (long int) p + PARA; if ( (owner = *((unsigned int huge *)(p+1))) != FP_SEG(q) ) { if ( (priown && (owner == priown) && ( ( ( (len = ( *((int huge *)(p+3)) ) * 16) > strlen(tststr) ) && !mycmp(q, tststr, strlen(tststr)) ) || ( (len > strlen(tststr2)) && !mycmp(q, tststr2, strlen(tststr2)))) ) ) { *el = len; return(q); } else p = q; } else { if ( (*((unsigned int huge *)(p + 0x2c + 0x10)) == 0) ) { priown = FP_SEG(q); p = q; } else if (dos33) { char huge *p33; FP_SEG(p33) = *((unsigned int huge *)(p + 0x2c +0x10)); FP_OFF(p33) = 0; q = p33; (long int) p33 -= PARA; len = ( *((int huge *)(p33+3)) ) * 16; if ( !(!mycmp(q, tststr, strlen(tststr)) || !mycmp(q, tststr2, strlen(tststr2)) ) ) return( (char huge *) 0l); *el = len; return(q); } else return( (char huge *) 0l ); } } } addpath(ep, esv, len, path) char huge *ep; char *esv; int len; char *path; { int l; char huge *eps; char huge *oldep; char *oldesv; oldep = ep; oldesv = esv; l = 0; while (*ep) { eps = ep; while (*ep) { if (l+3 > len) return(1); *esv++ = *ep++; l++; } if (!mycmp(eps, "PATH=", 5)) { if ( *path && ((esv[-1] == ';') ? 0 : ((esv[-1] == '=') ? 0 : 1)) ) { *esv++ = ';'; l++; } while (*path) { if (l+3 > len) return(1); *esv++ = toupper(*path++); l++; } } *esv++ = '\0'; ep++; } *esv++ = '\0'; ep = oldep; esv = oldesv; while (*esv) { while (*esv) *ep++ = *esv++; *ep++ = '\0'; esv++; } *ep++ = '\0'; return(0); } main(argc, argv) int argc; char *argv[]; { char huge *ep; int len; char *esv; union REGS dosregs; if (argc != 2) { printf("Usage: pathex pathstring\n"); exit(0); } dosregs.h.ah = 0x30; /* to get dos version */ intdos(&dosregs, &dosregs); switch (dosregs.h.al) { case 2: break; case 3: if (dosregs.h.ah == 30) dos33 = 1; break; case 4: /* I don't know if this will work */ dos33 = 1; break; default: printf("Dos version %d.%d not supported\n", dosregs.h.al, dosregs.h.ah); exit(0); } if ( (long int) (ep = findmast(&len)) ) { esv = malloc(len); if (addpath(ep, esv, len, argv[1])) printf("Failed to update Master Environment table (insufficient space)\n"); } else printf("Cannot locate Master Environment table\n"); } Robert Cawley rjc@atom.oz.au ANSTO
richard@iesd.auc.dk (Richard Flamsholt S0rensen) (03/13/90)
>mlord@bnr-rsc.UUCP (Mark Lord) writes: ><heath@ncrcae.Columbia.NCR.COM (Robert Heath) says: >< ><How can I set my dos PATH variable longer than 128 bytes? I'm running > >You need APPENV21.ARC from simtel20. I use it to set my own 500 byte PATH. ~~~~~~~~ 500 byte ?! Whatever happened to the idea about keeping all your batch-files in one directory, say C:\BATCH ?? My path covers DOS\DOS330, DOS\DOSEXTRA (system utilities, that I don't wanna mingle with "pure" DOS), BATCH and SYSTEM\NORTON - and thats it. I know, that some programs might cause trouble if they can't locate all of their files and that the usual solution is to either CD to the proper directory or to include that directory in your path. However, I've succesfully applied a number of other methods during the years so here's a few hints (they are all based on the idea about having a dedicated BATCH-directory holding all your batch files - and it's a neat idea!) 1 : Use APPEND to append a directory to the path, eg append c:\text\wp50 /* appends the directory */ c:\text\wp50\wp %1 /* better use absolute path ..*/ append ; /* skip the appended directory */ Since APPEND is a resident program, you'd better install it at startup time, by adding this to your AUTOEXEC.BAT: append c:\ /* install APPEND */ append ; /* forget the dummy-appending */ By doing this, you have full access to your wp50-directory and executing the batch file doesn't change your working directory. 2 : The appending of a directory to a path can also be done like this: set temp=%path% /* remember current path */ set path=%path%;c:\text\wp50 /* add directory */ c:\text\wp50\wp %1 /* same as before ... */ set path=%temp% /* restore old path */ set temp= /* delete "temp"-variable */ This assumes that you do *have* a path, but you probably do ... 3 : 4DOS-users could use the following approach, which is a bit easier: setlocal /* begin "local" mode */ set path=%path;c:\text\wp50 /* same as before */ c:\text\wp50\wp %& /* %& means "all arguments" */ endlocal /* back to normal ! */ 4 : The last resort (seem to remember, that GEM likes it this way) is to substitute a drive letter for the desired directory and change to that drive whenever you need to run the program. Usually, the need for this rarely happens, so you can set up the drives in your AUTOEXEC.BAT: subst e: c:\cad\gem (Remember to set lastdrive=z or something in your CONFIG.SYS) In the batch file, write (arrgh, need I elaborate - well, allright..) e: /* change to fake drive e: */ e:gemvdi %1 %2 %3 /* <hmm - is this the command ??> */ This can't get you back to your starting position when exeting the batch file, unless you use 4DOS or the like - here goes set temp=%disk /* remember the disk */ e: etc etc /* ho hum */ temp /* change back to <temp>-drive */ set temp= /* delete temp-variable */ (Actually, I haven't tried this one, but I'm 99.8% sure it works ...) Im sure there's a lot of other ways to handle this (like, say, invoking yet another command.com to run the batchfile, which therefore has a *copy* of the environment it can change anyway it prefers - or similar outrageous ideas !), but these have served me well for a long time - and I keep *my* path below 128 characters >:-) Bye now, Richard Flamsholt richard@iesd.auc.dk PS: Oh, and BTW, I don't have a directory called c:\text\wp50, but I *do* have c:\text\pctex and c:\text\emacs (need I say more ;-)
fredex@cg-atla.agfa.com (Fred Smith) (03/14/90)
Well, there are several ways around this problem. The problem is due, by the way, not to the length of the environment, but rather due to the fact that command.com allows only 127 bytes maximum on a command line. list of ways around it: 1. Do as others have suggested and use short directory names for all those places you want in the PATH. 2. Use the DOS subst command to make those long subdirectory names look like disk drives (which have a short name, don't they!) and then name the root directory of that "drive" in the path. I have done this in the past on several systems and never had a problem with it. 3. Use the program APPENV which appeared in one of the newsgroups here last summer. This is a TurboC program which adds the string given as its argument onto the end of the environment variable specified on its command line. I don't know where it is archived, but it might be simtel20. Fred Smith
marshall@wind55.seri.gov (Marshall L. Buhl) (03/15/90)
richard@iesd.auc.dk (Richard Flamsholt S0rensen) writes: >>mlord@bnr-rsc.UUCP (Mark Lord) writes: >><heath@ncrcae.Columbia.NCR.COM (Robert Heath) says: >>< >><How can I set my dos PATH variable longer than 128 bytes? I'm running >> >>You need APPENV21.ARC from simtel20. I use it to set my own 500 byte PATH. > ~~~~~~~~ Richard Flamsholt gives some very good suggestions about accessing programs without adding them all to the path. I have a minor quibble about his second technique, which, BTW, is the one I use. > 2 : The appending of a directory to a path can also be done like this: > set temp=%path% /* remember current path */ > set path=%path%;c:\text\wp50 /* add directory */ > c:\text\wp50\wp %1 /* same as before ... */ > set path=%temp% /* restore old path */ > set temp= /* delete "temp"-variable */ It is probably more efficient to change the second line to: set path=c:\text\wp50;%path% Since the whole purpose of this batch file is to run WP 5.0, why not put it in the beginning of the path so access is faster? -- Marshall L. Buhl, Jr. EMAIL: marshall@wind55.seri.gov Senior Computer Engineer VOICE: (303)231-1014 Wind Research Branch 1617 Cole Blvd., Golden, CO 80401-3393 Solar Energy Research Institute Solar - safe energy for a healthy future
mlord@bwdls58.bnr.ca (Mark Lord) (03/27/90)
In article <1990Mar14.172308.21398@seri.gov> marshall@wind55.seri.gov (Marshall L. Buhl) writes: <<<mlord@bnr-rsc.UUCP (Mark Lord) writes: <<<<How can I set my dos PATH variable longer than 128 bytes? I'm running <<<You need APPENV21.ARC from simtel20. I use it to set my own 500 byte PATH. << ~~~~~~~~ ...extended discussion deleted... <It is probably more efficient to change the second line to: < < set path=c:\text\wp50;%path% < <Since the whole purpose of this batch file is to run WP 5.0, why not <put it in the beginning of the path so access is faster? My opinion exactly. HOWEVER, even using the form: SET PATH=newdir;%PATH% is still subject to the 127 character limit (try it!). To extend beyond this requires a lot of monkeying around with SUBST, or artificial reorganising of directories to what MSDOS can handle, rather than what the user WANTS. As noted, APPENV21.ARC contains a simple (non-TSR) program to get around all of this. There are several other similar utilities around as well.
hovdesta@herald.usask.ca (Alfred Hovdestad) (03/28/90)
From article <2221@bwdls58.UUCP>, by mlord@bwdls58.bnr.ca (Mark Lord): > In article <1990Mar14.172308.21398@seri.gov> marshall@wind55.seri.gov (Marshall L. Buhl) writes: > <<<mlord@bnr-rsc.UUCP (Mark Lord) writes: > <<<<How can I set my dos PATH variable longer than 128 bytes? I'm running > <<<You need APPENV21.ARC from simtel20. I use it to set my own 500 byte PATH. > << ~~~~~~~~ ....extensiv discussion deleted... I have been following this discussion for several postings now and it seems to me that everyone is trying to kill a cockroach with a bazooka. Instead of always telling people that this is THE way to do what you are trying to do, why not find out if this is what he really needs. I ran into the same problem with my own path last year. I wanted to seperate my files into logical (to me) directorries, but I found that I could not get all the directories that I was using into my path. After looking at what I was doing, I came up with the following solution: I noticed that I has all of my language directories, and editor directories and communication directories always in my path. When I am writing a C program, I have no need for KERMIT in my path, same for CLIPPER. What I did was write a little batch utility like so: setpath.bat ------------------------------------ path=c:\;c:\dos;c:\bat;c:\bin;c:\pcwrite if "%1" == "" goto exit goto %1 :kermit path=%path%;c:\kermit goto exit :c path=%path%;c:\compiler\c goto exit :exit echo path ---------------------------------------------- and one like this: addpath.bat --------------------- if "%1" == "" goto exit path=%path%;%1 :exit echo path ------------------------------ This way, I was able to quickly change paths by entering setpath c without typing in the whole path. It also had the added benefit of increasing my search time because I was able to maintain a shorter path. A
donovan@atexnet.UUCP (Dennis Donovan) (03/30/90)
I used to use bigpath, which "doubles" the length of your path. The only thing I didn't like about it is that it takes a long time to execute and the PC (for some reason) didn't allow me to type ahead while I was waiting for it to finish. By a long time I mean 5-7 seconds during boot-up, well its a long time to me :-) They other day I finally got around to compiling and trying the "pathex" program posted either here, comp.sys.ibm.pc.programmer, or comp.binaries.ibm.pc.d. And it works great, it doesn't take as long and allows type ahead while it's doing its thing. If you didn't save it when you saw it, then by all means get it. Thanks to Robert Cawley (rjc@atom.oz.au), it complied like a charm and runs flawlessly. The best thing about it is that you can add to the path at the command line, unlike bigpath which has to be run in the autoexec.bat file. Dennis -------------------------------------------------------------------------------- +----------------------------------------------------------+ | Dennis L. Donovan | | UUCP : !uunet!atexnet!donovan | | AT&T : (617) 276-7349 | | USMAIL : Electronic Pre-Press Systems, Inc (EPPS,ATEX) | | 32 Wiggins Ave., M.S. 231/32W | | Bedford, MA 01730 | +----------------------------------------------------------+ "Nobody asked, just my opinion" Disclaimer: The views expressed are my own, I doubt if ATEX really cares anyway.
psm@manta.NOSC.MIL (Scot Mcintosh) (03/30/90)
In article <680@hawkeye.atexnet.UUCP> donovan@hawkeye.UUCP (Dennis Donovan) writes: > <says pathex program does good job of extending path beyond 128> >If you didn't save it when you saw it, then by all means get it. Where would pathex be archived?