Changing environment vars of parent process

What I'm looking to do is have my .exe set an environment variable in the calling .bat file. Basically looking for a source-equivalent of the SET command.

Is there any way to do this without kludges?

I looked into senvar by Ed Schwartz which claims to do the trick. But it seems to have no effect under XP. Then again at least it doesn't crash like some other approaches I've tried.

The current approach is something like:
myapp.exe > tempfile.bat
call tempfile

This, unfortuntely, is unacceptable due to the disk i/o. (The boss's constraint, not mine)

Any ideas?

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

Only the batch file needs to see it, and it only needs to persist until the batch is done running.

Piping the exe through SET /P _might_ be an acceptable solution, except for junking up the console with prompts. Would like to have all my alternatives on the table first before I approach him with my findings though.

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.

Hehehe a bag of sugar, classic.

I personally agree with everything that was said. To be honest I'm so far removed from where this is actually being used (in the departmental sense) that I'm not sure what oddities are going on which causes them to be so worried about a 15 bytes write for a few milliseconds. It's possible this is on a read only device, or perhaps writes are very expensive. I really do not know. I do know the batch(es) are extremely long running, as in they only get terminated when somebody/something kills them.

I will certainly attempt to discuss alternatives with him. I didn't think it was going to be a huge deal at the time since source was available for older windows versions.

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

Just an update:

Well, he let up a bit and we can now do this the "right" way: Have the exe call a second batch file thus inheriting the variables normally. So at least the practical problem was solved.