Using the environment won't work.

My recommendation is to simply use files to transfer the information.

For alternative approaches, see perlipc and the discussion in your previous thread. But none of the solutions beats using files written by the children and polling for these files in the parent for simplicity. Threads::Queue comes close, but only if you can write your children as threads instead of separate processes.

Depending on the size of information, you can even get by by appending to a single file and using File::Tail in the parent.

No file method wont work. If i have not conveyed the scenario properly, here it is, when a child returns to the parent ( after execution completion ) i have to check the environment variable PROJECTNAME, and according to that i have to process in the parent.

When the child exits, the child environment is lost.

No file method wont work.

Yes file method will work. :) The parent knows the pid of the child that just exited from the return value of wait. If each child writes the value of the PROJECTNAME "environment variable" just before it exits (you still haven't explained why it has to be an environment variable) to a file (pid.tmp, say), the parent can read the value of PROJECTNAME from the pid.tmp file.

You still haven't explained the bigger picture, what is the type of problem you are trying to solve, and why running multiple sub processes is a good way to solve it. And do you really need environment variables? Or do you just need a decent IPC mechanism?

That is what i asked how to get the environment variable from the child process to the parent process.

I'd use exit values or pipes to solve your problem.

As a blanket statement, I would advise that you don’t eer expect the parent of a process (or, any other process) to have “specialized knowledge” about another process, nor to magically rendezvous with one.

If you need to obtain information from the child, have the child give it to the parent by some sharing-friendly mailbox or queue.

There are a lot of things (like this) that “look good in testing” and “seem to work okay,” that will have you fall flat on your “*” in production.   :-}