Thread: Changing environment vars of parent process

There's putenv() and getenv() for accessing/modifying the environment of your process. There's no straight-forward way of modifying the environment of another process if that's what you're asking.

If you explain the problem you are trying to solve by modifying another processes environment - perhaps we can come up with a better solution.

gg

Yes, I'm well aware of getenv/putenv. Just for background I have been a professional C/C++ programmer for over 14 years.

The client runs his whole server farm using batch files, so he is heavily dependent on variables inside of them. This exe I've created communicates across the network with other machines, grabs data, and is supposed to pass a variable to the batch file.

This exe of mine simply outputs this to stdout:
SET myvar=somedata

Again, this kludge works by the use of:
myapp.exe > temp.bat
call temp.bat ; (sets myvar=somedata)

But we need to do this without using the temporary file.

As for a better way of solving the problem, sure I could tell him to ditch all his batch files and hire me to rewrite everything using real IPC. But the customer is always right even when he's wrong.

I'm not looking for an alternative to batch files, I have no choice. I'm also not looking for a "straightforward" way, as I realize it will not be straightforward. The .com file source I linked to in my original post would have been ideal if it worked in a 32 bit environment. Unfortunately it does not seem to.

So who needs to see this new/changed environment variable? And how long does it need to persist?

gg

Call putenv() and run the batch file yourself. Child processes inherit the environment of their parent. You'll want to run "cmd /c xyz.bat".

gg

> This, unfortuntely, is unacceptable due to the disk i/o. (The boss's constraint, not mine)
a) why hasn't your boss got better things to worry about?
b) how much disk I/O has already occurred to get the command interpreter loaded, the batch file loaded and your executable loaded. No doubt there's a bunch more disk i/o to come, following the setting of the variable.

I mean, it's not going to be a large file - no more than one cluster, and if you delete it as soon as you call it, it might not even last long enough to get out of cache before it's gone.

Tell your boss to go to the grocery store to buy a bag of sugar.
Then tell your boss to complain that there's one grain too many in the bag.
Then ask your boss to analyse the range of responses he'll get to such a request.

Or how about put a monetary value on all the time you're wasting coming up with bizarre ways of solving the problem when the simple and obvious one would have taken no time at all.

Meh, just do this

del /q temp.bat
myapp.exe >> temp.bat
call temp.bat

If he asks what >> is, just tell him that it's the FAST version of >

> It's possible this is on a read only device,
Use %TEMP%\temp.bat then as the temporary file.

> or perhaps writes are very expensive.
Which would make any decent sized program run in weeks rather than minutes.
If it were that slow to cause your solution to be a problem.

You could install a ramdisk and use it for the temporary. But that's not as easy as following post #6.

gg