Date: Tue, 7 Feb 1995 03:22:17 -0400 (AST)
From: Bill Davidson <bdavidson AT ra DOT isisnet DOT com>
Subject: Re: putenv() and system() 
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: Long Doan <ldoan1 AT osf1 DOT gmu DOT edu>, djgpp AT sun DOT soe DOT clarkson DOT edu


On Tue, 7 Feb 1995, Eli Zaretskii wrote:

> > When the program calls putenv (), it only modifies its own copy of the 
> > environment, which will be coppied to the child process's stack. But 
> > when system () is called, command.com looks at DOS's copy of the 
> > environment, which doesn't have the modification.
> 
> That copy to child's stack happens only when spawn() is called.
> This is different from other DOS compilers, where putenv() also
> affects system().  Fortunately, in v2.0 system() calls spawn().

I believe that Long Doan's description above more correctly expresses 
what I was getting at.  I have always thought that this was a peculiarity 
of DOS, which doesn't like you messing with the master environment block 
(yes, I know it can be done, but I also know how difficult it is).  I 
will try under Turbo C and see if putenv() affects system().
Getting back to your original post, could you try something like:
	system("set var_to_change=new value");
	system("do_something");
?  I have a feeling even that won't work.  Ever try to "set" while 
running Norton Commander?  It just don't work; even the local copy of the 
environment is unchanged.  I think what happens there is command.com gets 
its own fresh copy of environment, changes it, and control reverts to 
nc.exe whose environment hasn't been touched.  I went crazy one day 
trying to set up an environment variable for gnuplot while nc was 
active.  I finally typed "set gnuhelp=c:\..." then immediately typed 
"set" and saw what was going on (and realized I should have known...).
Bill Davidson
bdavidson AT ra DOT isisnet DOT com