Path: utzoo!utgpu!water!watmath!clyde!att!mtunx!whuts!mhuxh!mhuxu!aluxs!aluxp!wg
From: wg@aluxp.UUCP (Bill Gieske)
Newsgroups: comp.sys.ibm.pc
Subject: help re. environment size
Keywords: command.com, environment
Message-ID: <968@aluxp.UUCP>
Date: 7 Jun 88 14:59:36 GMT
Organization: AT&T Bell Laboratories, Murray Hill, NJ
Lines: 30

I have been absent from netnews for some time, but gather a means of patching
command.com was posted, as an alternative to specifying the environment size
with the /e qualifier in config.sys.

I missed the posting on the patch.  Would someone please email same to me?

My experience with this issue leaves me questioning whether even this complete-
ly addresses the issue.  I am running 3.1 on a Leading Edge.  Long before I 
knew about modifying the environment with /e (not documented in 3.1), I dis-
covered I could get a longer path string (up to 128 instead of 64) by invoking
a secondary batch file from autoexec.bat.  Most programs worked fine, i.e. they
recognized more than 64 bytes in the string.  A few didn't.

By using the /e qualifier in autoexec.bat, I could eliminate the secondary
batch file, and still have a path up to 128.  But not more.

However, not all is well.  I have two versions of a data base package, only one
of which I want in the search path at any given time.  Thus, I reissue the path
command with appropriate changes.  When done, I restore the path string to that
specified at boot-up.  I've noticed that one program in particular which ac-
cesses the path in executing a batch file as the menu choice does not work un-
less I reboot.  Something is not as it should be in the environment space.

Incidentily, with environment space expanded, the path statement is still limit-
ed to up to 128 (more like 125) bytes.

Thanks in advance!

Bill Gieske
aluxp!wg