larsen@mist.cs.orst.edu (Scott Larsen) (03/07/90)
I recently changed my autoexec file to set a few more environment var's, and now I get the message: Out of environment space Does this mean I cannot set anymore environment variables? Is there a way to get around this? -Scott Larsen larsen@cs.orst.edu UUCP: hplabs!hp-pcd!orstcs!larsen -------------------------------------------------------------------------- "Open the pod bay doors, Hal." - David Bowman
LC.YRS@forsythe.stanford.edu (Richard Stanton) (03/08/90)
In article <16558@orstcs.CS.ORST.EDU>, larsen@mist.cs.orst.edu (Scott Larsen) writes: >I recently changed my autoexec file to set a few more environment var's, >and now I get the message: > >Out of environment space > In your CONFIG.SYS file, put the line: SHELL=c:\command.com /p /E:2048 or similar, where you should use the correct path for your system, (note that if it is not in the root directory, DOS will set COMSPEC to the correct disk, but not to the right path, so you may have to set this manually). the /E parameter says how much space (in bytes) should be used for the environment (I believe that for MD-DOS <=3.1 or thereabouts, the number was a number of paragraphs, but the above is definitely true for 3.3 and above). Richard Stanton
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (03/08/90)
In article <16558@orstcs.CS.ORST.EDU> larsen@mist.CS.ORST.EDU (Scott Larsen) writes:
$I recently changed my autoexec file to set a few more environment var's,
$and now I get the message:
$Out of environment space
$Does this mean I cannot set anymore environment variables? Is there a way
$to get around this?
Well, it means what it says - there's a given amount of space available
for environment variables, and you're trying to use more than that amount.
There is an easy way to change this, depending on what version of DOS you're
using.
For DOS 2.x (and also possibly 3.0 - I'm not sure), you can't change the
amount of space for environment variables without patching COMMAND.COM.
For more recent versions, you need a line line the following:
shell=c:\command.com/p/e:xxx
in your config.sys file (obviously, if your command.com isn't found as
c:\command.com, you would insert the appropriate path). The /p switch
is very important - it means "permanent", so that you can't exit out of
that level and so that it executes autoexec.bat.
Now for that /e:xxx switch. This specifies the amount of environment
space. For recent versions of DOS (3.3 and later, possibly also 3.2 - I'm
not sure), the xxx is the number of bytes to be allocated for the
environment (it will be rounded up to the nearest paragraph; a paragraph
is a 16-byte chunk). For earlier versions, the xxx is the number of
paragraphs to allocate. Check your DOS manual for details on exactly
how to do this for your version of DOS.
How much space do you need? Well, for each string of the form
varname=value
you need one byte for each character in that entire line (so the
above would take 7 + 1 + 5 = 13), plus one for a sentinel (a zero byte)
which DOS adds to the end of it, so we need 14 bytes for that. In
addition, there is a second sentinel byte after the very last string
in the table. When calculating, don't forget to leave room for
additions and changes to your environment table which may be made
after you boot the machine!
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
"Oooh yes I need some love" - Rushjcb2647@cec1.wustl.edu (James Christopher Beard) (03/09/90)
A previous response (13116) gave sound info on how to enlarge the amount of space COMMAND.COM sets aside for the environment. There is another way to get "Out of environment space" messages, though: When "shelling out" of (executing command.com from within) another program, some versions of DOS strip away all unused space from the copy of the environment they give you. Thus you may have had only 188 bytes of a 512 byte environment used up, but when you shell out of Word (or whatever) you have 188/188 bytes taken. One way around this works only with batch files: before invoking the program you may want to shell out of, have a line like "SET BUF=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx". Then, when you're in the secondary shell, issue "SET BUF=", freeing up as many bytes as there were x's (plus a few). This second step must be repeated each time you shell out. PC-DOS 3.1 doesn't do the above squeezing of child environments, but PC-DOS 3.2 does. Another reason to either upgrade (to 4.01) or downgrade (to 3.1) from 3.2. (Others include the floating-point bug in 3.2, purported bug in XCOPY, and the fact that 3.2 consumes substantially more memory than 3.1 but not significantly less than MS-DOS 4.01.)
bob@omni.com (Bob Weissman) (03/09/90)
In article <8377@lindy.Stanford.EDU>, LC.YRS@forsythe.stanford.edu (Richard Stanton) writes: > In your CONFIG.SYS file, put the line: > > SHELL=c:\command.com /p /E:2048 > > or similar, where you should use the correct path for your system, > (note that if it is not in the root directory, DOS will set COMSPEC > to the correct disk, but not to the right path, so you may have to > set this manually). If you give COMMAND an argument consisting of a drive and directory, COMSPEC gets set correctly. So the above line should read: SHELL=C:\COMMAND.COM C:\ /P /E:2048 -- Bob Weissman Internet: bob@omni.com UUCP: ...!{apple,pyramid,sgi,tekbspa,uunet}!omni!bob
dell@pmday_1.Dayton.NCR.COM (Jim Dell) (03/09/90)
In article <16558@orstcs.CS.ORST.EDU> larsen@mist.CS.ORST.EDU (Scott Larsen) w >I recently changed my autoexec file to set a few more environment var's, >and now I get the message: > >Out of environment space > >Does this mean I cannot set anymore environment variables? Is there a way >to get around this? > Enter the following in your Config.sys file shell = c:\command.com /e:256 /p The e: parameter tells DOS how much to allocate, in this case 256 bytes Hope this helps -- Jim Dell e-mail: NCR Corporation Jim.Dell@dayton.NCR.COM 1334 South Patterson Blvd. (513)-445-4181 Dayton, OH 45479 622-4181 (VoicePlus)
richard@calvin.spp.cornell.edu (Richard Brittain) (03/09/90)
In article <1990Mar8.162123.4418@cec1.wustl.edu> jcb2647@cec1.wustl.edu (James Christopher Beard) writes: >some versions of DOS strip away all unused space from the copy of the >environment they give you. Thus you may have had only 188 bytes of >a 512 byte environment used up, but when you shell out of Word (or >whatever) you have 188/188 bytes taken. [set large variable, then delete and reuse space] >PC-DOS 3.1 doesn't do the above squeezing of child environments, but >PC-DOS 3.2 does. Another reason to either upgrade (to 4.01) or >downgrade (to 3.1) from 3.2. Actually, 4.01 does squeeze child environments, but command.com is different from most programs in having it's environment block follow it in memory. Command.com can therefore dynamically expand it's environment as needed, when you set long strings in a child shell. It chokes when it reaches the value you specified on the SHELL= line. Given this action, I don't know why the /E:nnn is even needed, since the environment can always expand as needed. Note that this behaviour is a function of command.com, not msdos as such. Naughty programs which try to change the parent environment usually fail with this scheme, since they cannot expand it. The trick of creating a long dummy string and then deleting it will allow such programs to function. If you run "mem /debug", then set a long variable, then run it again, you can see the environment block get larger by paragraphs. If anyone really needs a "global environment" writable and readable by all programs, DDJ published one a few months ago, implemented as a device driver. 4dos puts the environment into the "swappable" code, then makes a shrunk copy in low memory before running a program. Since I just mentioned 4dos, and rumors of v 3.0 are running around, I'll just mention that among the new features I believe will be: - redirectable i/o from batch files - if .. elseif .... else .... in batch files - new kind of batch files executed enirely from memory (instead of re-reading the file for each line the way command.com does.) This is not official in any way of course, but I exchanged e-mail with one of the authors and he didn't say it was secret. Personally I can't wait to see what else is in there. Richard Brittain, School of Elect. Eng., Upson Hall Cornell University, Ithaca, NY 14853 ARPA: richard@calvin.spp.cornell.edu UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richard
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (03/10/90)
In article <1990Mar8.162123.4418@cec1.wustl.edu> jcb2647@cec1.wustl.edu (James Christopher Beard) writes:
$ [...] Another reason to either upgrade (to 4.01) or
$downgrade (to 3.1) from 3.2. (Others include the floating-point bug
$in 3.2 [...]
What floating-point bug? DOS doesn't handle floating-point math.
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
"Oooh yes I need some love" - Rushralf@b.gp.cs.cmu.edu (Ralf Brown) (03/10/90)
In article <25F7EFC0.10904@maccs.dcss.mcmaster.ca> cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes: }In article <1990Mar8.162123.4418@cec1.wustl.edu> jcb2647@cec1.wustl.edu (James Christopher Beard) writes: }$ [...] Another reason to either upgrade (to 4.01) or }$downgrade (to 3.1) from 3.2. (Others include the floating-point bug }$in 3.2 [...] } } What floating-point bug? DOS doesn't handle floating-point math. From the Turbo C 1.5 README file: DOS 3.2 has a bug in its handling of floating exceptions. When an exception occurs, the system allocates a local stack for the exception handler. Unfortunately, when a system stack gets allocated, it never gets deallocated. The default number of stacks is 8. After 9 floating point exceptions occur, the system hangs and a cold reboot is required. Typical exceptions are overflow and divide by zero. The stacks are not reclaimed when a program terminates, so a program which divides by zero once will crash the machine if run 9 times. To avoid this problem, you can either: 1. Not use DOS 3.2. 2. Obtain a patch from IBM or Microsoft which fixes the bug, and install it on your copy of DOS. 3. Not use a floating point coprocessor. 4. Disable the exception trapping in your Turbo C program. You can do this easily by calling the _clear87() library function. For example, -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/46 BITnet: RALF%CS.CMU.EDU@CMUCCVMA AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? | _How_to_Prove_It_ by Dana Angluin 3. by vigorous handwaving: What's that?| Works well in a classroom or seminar setting.
kabra437@pallas.athenanet.com (Ken Abrams) (03/13/90)
In article <699@pmday_1.Dayton.NCR.COM> dell@pmday_1.Dayton.NCR.COM (Jim Dell) writes: > >shell = c:\command.com /e:256 /p > >The e: parameter tells DOS how much to allocate, in this case 256 bytes > I thought I had seen this discussed on here....... My shell statement is as shown above with /e:512. Works fine. My problem goes one step beyond this. How do you get a child shell to inherit more that the default amount of environment space? Specifically, when I shell out of an application, I end up with only the 160 byte default environment in the child shell. Since the child inherits about 155 bytes from the parent, this doesn't leave me much to play with. Now that I think about it a little more, it seems like I saw a post about padding out the top level environment with a bunch of "filler" assignments and them deleting them in the child environment. Is there no better way? This seems like a terrible kludge. -- ======================================================== Ken Abrams uunet!pallas!kabra437 Illinois Bell kabra437@athenanet.com Springfield (voice) 217-753-7965