You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by David Forslund <dw...@lanl.gov> on 2000/08/10 17:10:29 UTC
Re:
I was using the <env> argument to pass a "classpath" to my
executable. This now seems
to be broken. I'm using the following
<env key="CLASSPATH" path="${variable.path}"/>
The program can't find the class in ${variable.path} and I can't get the
-verbose flag to tell me what was actually passed
to the executable.
This is with the current CVS repository.
David W. Forslund dwf@lanl.gov
Advanced Computing Laboratory http://www.acl.lanl.gov/~dwf
Los Alamos National Laboratory Los Alamos, NM 87545
505-665-1907 FAX: 505-665-4939
RE:
Posted by Conor MacNeill <co...@m64.com>.
> -----Original Message-----
> From: David W Forslund [mailto:dwf@lanl.gov]
> Sent: Monday, 14 August 2000 23:54
> To: ant-dev@jakarta.apache.org
> Subject: RE: <arg>
>
>
> Why can't one obtain the PATH variable (or others) that ant has and
> optionally add to that environment for a exec task? Can this be
> done portably?
>
David,
Java itself does not make the current path available. Perhaps it is too
platform-specific a concept. For ant to "know" the value of the system path,
it would need to be told explicitly.
Conor
RE:
Posted by David W Forslund <dw...@lanl.gov>.
Why can't one obtain the PATH variable (or others) that ant has and
optionally add to that environment for a exec task? Can this be done portably?
Conor MacNeill writes:
> Louis,
>
> > I don't think you can make any portable assumptions about
> > java.library.path. Unless someone can point to a specification,
> > I believe it's safer for the scripts to explicitly pass the current PATH
> > as a system property ("ant.system.path" or something) on the command
> > line.
> >
>
> I agree that we cannot rely on java.library.path. However I wonder if
> passing in the Path as an ant property is the start of a slippery slope
> where we end up trying to pass the whole environment into ant :-) Currently
> we have
>
> ant.home
> jikes.class.path
>
> We probably could add what you suggest, but what else (wheeeee down we go
> !!)
>
> Conor :-)
>
>
--
David Forslund Voice:(505) 665-1907
Advanced Computing Laboratory, MSB287 FAX: (505) 665-4939
Los Alamos National Laboratory EMAIL: dwf@lanl.gov
Los Alamos, NM 87545 WWW: http://www.acl.lanl.gov/~dwf
Re:
Posted by Louis Tribble <lo...@metamata.com>.
Conor MacNeill wrote:
>
> Louis,
>
> > I don't think you can make any portable assumptions about
> > java.library.path. Unless someone can point to a specification,
> > I believe it's safer for the scripts to explicitly pass the current PATH
> > as a system property ("ant.system.path" or something) on the command
> > line.
> >
>
> I agree that we cannot rely on java.library.path. However I wonder if
> passing in the Path as an ant property is the start of a slippery slope
> where we end up trying to pass the whole environment into ant :-) Currently
> we have
>
> ant.home
> jikes.class.path
>
> We probably could add what you suggest, but what else (wheeeee down we go
> !!)
>
> Conor :-)
I can't argue with your concern, but PATH is ubiquitous on Windows
and Unix (and has no equivalent on Mac OS < 10). Jesse's "heinous"
hack _would_ short-circuit this debate...
Louis (the on-vacation version)
--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Louis Tribble louis@metamata.com
Metamata, Inc. http://www.metamata.com
Tools for serious Java developers. +1 510 796 0915
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
RE:
Posted by Conor MacNeill <co...@m64.com>.
Louis,
> I don't think you can make any portable assumptions about
> java.library.path. Unless someone can point to a specification,
> I believe it's safer for the scripts to explicitly pass the current PATH
> as a system property ("ant.system.path" or something) on the command
> line.
>
I agree that we cannot rely on java.library.path. However I wonder if
passing in the Path as an ant property is the start of a slippery slope
where we end up trying to pass the whole environment into ant :-) Currently
we have
ant.home
jikes.class.path
We probably could add what you suggest, but what else (wheeeee down we go
!!)
Conor :-)
Re:
Posted by Louis Tribble <lo...@metamata.com>.
Stefan Bodewig wrote:
>
> As others have pointed out, it's a all or nothing thing. Once you send
> any environment variables to the subprocess, you have to set them all.
>
> I've put a warning into docs/index.html about this when I documented
> <env> two days ago. I don't think Ant has a way to circumvent this.
>
> For PATH it looks like the System property java.library.path holds
> this information (at least on all Sun/Blackdown/IBM JDKs on Linux and
> Sun's JDKs on Windows) although it's not documented anywhere as far as
> I can tell.
>
> This means, you can use <env key="PATH" value="${java.library.path}" />.
>
> Stefan
I don't think you can make any portable assumptions about
java.library.path. Unless someone can point to a specification,
I believe it's safer for the scripts to explicitly pass the current PATH
as a system property ("ant.system.path" or something) on the command
line.
Louis
--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Louis Tribble louis@metamata.com
Metamata, Inc. http://www.metamata.com
Tools for serious Java developers. +1 510 796 0915
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Re:
Posted by Jesse Glick <Je...@netbeans.com>.
Stefan Bodewig wrote:
> As others have pointed out, it's a all or nothing thing. Once you send
> any environment variables to the subprocess, you have to set them all.
>
> I've put a warning into docs/index.html about this when I documented
> <env> two days ago. I don't think Ant has a way to circumvent this.
If you wanted to be perverse I guess you could have Ant lazily run as a
subprocess "env" (Unix) or "set" (Windows; is this right?), gather the
results, parse them, and use them as defaults when <env> vars were
specified in exec tasks (in Execute.setEnvironment). A heinous
workaround for a dumb JDK bug.
-J.
--
Jesse Glick <ma...@netbeans.com>
NetBeans, Open APIs <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR
Re:
Posted by Stefan Bodewig <bo...@bost.de>.
As others have pointed out, it's a all or nothing thing. Once you send
any environment variables to the subprocess, you have to set them all.
I've put a warning into docs/index.html about this when I documented
<env> two days ago. I don't think Ant has a way to circumvent this.
For PATH it looks like the System property java.library.path holds
this information (at least on all Sun/Blackdown/IBM JDKs on Linux and
Sun's JDKs on Windows) although it's not documented anywhere as far as
I can tell.
This means, you can use <env key="PATH" value="${java.library.path}" />.
Stefan
Re:
Posted by David Forslund <dw...@lanl.gov>.
I still don't see the environment passed, but I do see that if I set the
PATH variable, my CLASSPATH environment
must not be passed. I have to set both PATH and CLASSPATH to get my
environment to my application.
I guess I don't understand why this needs to be the case.
Dave
At 05:34 PM 8/10/00 +0200, Stefan Bodewig wrote:
> >>>>> "DF" == David Forslund <dw...@lanl.gov> writes:
>
> DF> I can't get the -verbose flag to tell me what was actually passed
>
>I've just checked in a version that should list the environment passed
>to the sub process.
>
>Stefan
Re:
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "DF" == David Forslund <dw...@lanl.gov> writes:
DF> I can't get the -verbose flag to tell me what was actually passed
I've just checked in a version that should list the environment passed
to the sub process.
Stefan