You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Kev Jackson <ke...@it.fts-vn.com> on 2005/03/01 05:16:38 UTC
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Execute. getProcEnvironment()
Posted by Steve Loughran <st...@apache.org>.
Kev Jackson wrote:
> 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?
>
I dont either, but my linux box does have a copy of vmware, and I do
have an MSDN subscription. So in theory, I could build up a copy just
for testing. Keep it off the public network, only install the bare
minimum of stuff (java, ant, jedit) and I've a lightweight image with
minimal security risks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Execute. getProcEnvironment()
Posted by Darin Swanson <Da...@us.ibm.com>.
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 <ke...@it.fts-vn.com>
02/28/2005 08:16 PM
Please respond to
"Ant Developers List"
To
Ant Developers List <de...@ant.apache.org>
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org