Re: Execute. getProcEnvironment()

[Darin Swanson]

For the Eclipse  bug report for this problem see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=50567
The implementation is in 
org.eclipse.debug.internal.core.LaunchManager.getNativeEnvironment()
This was put into Eclipse 3.0 to fix the hang for us.

HTH
Darins




Kev Jackson <[EMAIL PROTECTED]> 
02/28/2005 08:16 PM
Please respond to
"Ant Developers List"


To
Ant Developers List <[EMAIL PROTECTED]>
cc

Subject
Re: Execute. getProcEnvironment()






Steve Loughran wrote:

> seeing the install notes for eclipse shows up what they think are 
> troublespots with ant, one of them being
>
> that <property environment="env" /> hangs: 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=26770
>
> I think we ought to take a look at this code, and rework it some more. 
> It is all built around executing external code to find out env 
> properties, when now, with Java1.5, we can get it from the system 
> environment -execing programs should be our fallback on older systems.

Adding support to check with Java5 is trivial, the harder part will be 
the hoops you have to jump through for win9x.  The suggested fix in the 
bugrep is to dump the values out to a file and then read the file, not 
System.out, would it be better to do this only for win9x, or to do it 
for all OSs?

 public static synchronized Vector getProcEnvironment() {
        if (procEnvironment != null) {
            return procEnvironment;
        }
        procEnvironment = new Vector();
 
        //use Java5 funtionality to get environment
        if (JavaEnvUtils.getJavaVersion().equals(JavaEnvUtils.JAVA_1_5)) {
            procEnvironment.addAll(System.getenv().entrySet());
            return procEnvironment;
        }
 
        try {
            ByteArrayOutputStream out = new ByteArrayOutputStream();
            Execute exe = new Execute(new PumpStreamHandler(out));
            exe.setCommandline(getProcEnvCommand());
            // Make sure we do not recurse forever
            exe.setNewenvironment(true);
            int retval = exe.execute();
            if (retval != 0) {
                // Just try to use what we got
            }
 >>> would it be better to check for win9x here and execute a completely 
different set of operations, or
[
            BufferedReader in =
                new BufferedReader(new StringReader(toString(out)));

            if (Os.isFamily("openvms")) {
                procEnvironment = addVMSLogicals(procEnvironment, in);
                return procEnvironment;
            }
            String var = null;
            String line, lineSep = System.getProperty("line.separator");
            while ((line = in.readLine()) != null) {
] rewrite this so that it always looks for a file containing the env 
variables?

The problem with checking for win9x is having specialized code just for 
one platform, but to rewrite so that every OS uses a file to dump out 
the variables would require changing getProcEnvCommand for all OSs and 
testing on all OSs (a headache to say the least), although having the 
same behaviour would probably be easier to maintain in the long run.

Also if you dump out the variables to a file, it'd be nice to remove the 
file when you've finished with it, both of my suggestions would require 
some tidying afterwards, so they're both equally bad for that!  Is there 
any evidence that the "dump to file" will actually solve this "hang" 
before trying to implement it?  I can't test this as I don't have any 
win9x systems available.  Does anyone else still have ancient versions 
of windows for testing purposes?

Thoughts &c

Kev

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]