You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Julien Couvreur <jc...@redcart.com> on 2000/07/14 23:30:07 UTC
Controling the environment for exec tasks
Hi,
Somebody posted a message saying what he greatly enjoyed with Ant was the
possibility of not depending on the system environment (ie CLASSPATH
especially).
You may want to call third-party scripts from ant, and these may (and often)
need to run in a special environment. So it would be nice if exec could
specify env variables for the program that we exec.
Unfortunately, maybe Java doesn't support changing environment variables (it
only allows reading, via System.getXxx()). Would there still be a way of
doing this env variable setting ?
Julien Couvreur
RedCart, Enabling Digital Marketplaces.
http://www.redcart.com
Re: Controling the environment for exec tasks
Posted by Jesse Glick <Je...@netbeans.com>.
Julien Couvreur wrote:
> Unfortunately, maybe Java doesn't support changing environment variables (it
> only allows reading, via System.getXxx()). Would there still be a way of
> doing this env variable setting ?
You can pass in environment variables using Runtime.exec (only affects
the subprocess, not the calling VM!). This ought to work on Windows and
Unix both without any wrapper scripts, AFAIK. Also in 1.3 *only* you can
set the working directory for the subprocess as well (you could test for
this ability using introspection on Runtime.class).
-Jesse
--
Jesse Glick <ma...@netbeans.com>
NetBeans, Open APIs <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR
RE: Controling the environment for exec tasks
Posted by Conor MacNeill <co...@m64.com>.
I have a version of antRun.bat that will handle any number of arguments by
shifting. There was, however, a discussion in February about all this and I
dimly recall there were some issues about how this shifting would work. I
have tested my version on Win98 with reasonable results. Can anyone remember
the issues?
Conor
> -----Original Message-----
> From: Jimmy Sieben [mailto:jimmys@utdallas.edu]
> Sent: Monday, 17 July 2000 21:42
> To: ant-dev@jakarta.apache.org
> Subject: Re: Controling the environment for exec tasks
>
>
> At 01:56 AM 7/17/2000, you wrote:
> > PD> and also may limit on win32 systems that I believe can only take
> > PD> 10 parameters in batch files.
> >
> >9, I think.
>
> Actually, you can pass a batch file any number of arguments. However, I
> believe you can only address 9 of them directory with the %n notation;
> thus, to get to extra arguments, you have to shift some off first. Just a
> nitpick though :)
>
> +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
> | Jimmy Sieben <> jimmys@utdallas.edu <> EvlG@IRC <> Young Game Designer |
> | ICQ UIN: 650255 <> Most things suck, thats what makes some things rock |
> | Homepage: http://www.utdallas.edu/~jimmys/ |
> +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
>
>
Re: Controling the environment for exec tasks
Posted by Jimmy Sieben <ji...@utdallas.edu>.
At 01:56 AM 7/17/2000, you wrote:
> PD> and also may limit on win32 systems that I believe can only take
> PD> 10 parameters in batch files.
>
>9, I think.
Actually, you can pass a batch file any number of arguments. However, I
believe you can only address 9 of them directory with the %n notation;
thus, to get to extra arguments, you have to shift some off first. Just a
nitpick though :)
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Jimmy Sieben <> jimmys@utdallas.edu <> EvlG@IRC <> Young Game Designer |
| ICQ UIN: 650255 <> Most things suck, thats what makes some things rock |
| Homepage: http://www.utdallas.edu/~jimmys/ |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
Re: Controling the environment for exec tasks
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "PD" == Peter Donald <do...@mad.scientist.com> writes:
PD> The problem I see is that that means all tasks will be forced to
PD> go through an antRun.[bat|sh]
Hmm, only those that needed it, Exec namely.
PD> and also may limit on win32 systems that I believe can only take
PD> 10 parameters in batch files.
9, I think.
There is a Runtime.exec method that takes an array of command line
args and one of environment variables. Would this use up parameters
passed to the batch file on windows systems?
My interpretation of this is more something like "set up the Process
environment to include the specified variables and their values, then
call the script".
Stefan
RE: Controling the environment for exec tasks
Posted by Peter Donald <do...@mad.scientist.com>.
At 05:03 16/7/00 -0700, you wrote:
>would rather pile up the env string (which should look like "key=value" for
>example, as in bash).
>So it would look like <exec ..... env="key1=value1" env="key2=value2" />.
Wouldn't work in general case.
>Next, I would look better if it was rather like :
><exec ...>
> <env key="k1" value="v1"/>
> <env key="k2" value="v2"/>
></exec>
Much better. The problem I see is that that means all tasks will be forced
to go through an antRun.[bat|sh] which is a overhead (2 processes rather
than 1) and also may limit on win32 systems that I believe can only take 10
parameters in batch files.
The only *general* solution I can think of is to write scripts that read
from standard in to get environment/other parameters/executable name. Then
change the java code to write stuff to standard in with certain seperators.
Ugly - hell yes. Workable ? I guess so.
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Controling the environment for exec tasks
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "JC" == Julien Couvreur <jc...@redcart.com> writes:
JC> Hi, First, thanks to all you guys answering ! That's really
JC> great.
JC> Now,
>>> Yes, that'd be the way to go, and maybe if value was omitted use
>>> System.getenv to get the current value?
JC> Are the current values not passed by default.
I thought they wouldn't if you specify the environment explicitly,
i.e. use one of the two argument Runtime.exec methods. So I went on
and tried it and:
Exception in thread "main" java.lang.Error: getenv no longer supported, use properties and -D instead: SSH_AGENT
on System.getenv("SSH_AGENT")
so there is nothing much we could do anyway - seems like they start
adding meaning to the deprecation tags.
JC> Also, could somebody give me (or us) a hint why antRun is
JC> involved ?
You cannot change the working directory of a process in Java - but we
do have a dir attribute in Exec. The script just changes the directory
and calls the intended program after that.
JC> About the createXXX and addXXX :
JC> - what is the difference between create and add.
If you use createXXX, it's the responsibility of the task to create an
instance of the "nested" class. Using addXXX this will be done from
the IntrospectionHelper. That's all.
Sometimes it's impossible to do the right thing from outside (if the
class returned doesn't have a public constructor or you don't want to
create a new instance every time - see Path for example), then
createXXX is the way to go. Sometimes there is no special magic
necessary (I envision setting environment variables to be such a case)
so you can happily stick with addXXX.
JC> - why not put a small example with createXXX, addXXX, and Class
JC> ReturnObject ?
If I had time ...
JC> - what constraints is there on the ReturnObject ?
None if you use the createXXX methods. To be eligible for the addXXX
method, the class must have a public no arg constructor.
Stefan
RE: Controling the environment for exec tasks
Posted by Julien Couvreur <jc...@redcart.com>.
Hi,
First, thanks to all you guys answering ! That's really great.
Now,
>> Yes, that'd be the way to go, and maybe if value was omitted use
>> System.getenv to get the current value?
Are the current values not passed by default. Under Unix the environment is
passed to the "son" created with "fork". Under Win32 I don't know. So "env"
or "setenv" or what ever it gets called would just overload and override the
environment.
Also, could somebody give me (or us) a hint why antRun is involved ? What is
it used for ? I'll go in Exec.java anyway, but having an overall picture is
always nice to catch up on the code : )
>> Take a look at the modifications I've made to
>> docs/index.html#writingowntask and tell me if that makes sense to you
>> - and post any corrections please, English is not my native language.
About the createXXX and addXXX :
- this added documentation is mostly clear, as far as my english goes too !
- what is the difference between create and add. I went in
"MatchingTask.java" and there is only createInclude and createExclude, but
no addXXX.
- why not put a small example with createXXX, addXXX, and Class ReturnObject
? Or maybe just give a couple adequat classes reference in the Ant sources ?
- what constraints is there on the ReturnObject ? It seems to be constructed
as the task itself, with setters, but is it all ?
I will repost soon about the issue I had with "notavailable" and negation in
general.
And also, the building issue : chossing ant.build.dir=. could bring
something nicer than what it does (try it ! ;-).
See ya
Julien
Re: Controling the environment for exec tasks
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "MS" == Malcolm Sparks <ma...@iona.com> writes:
>> Yes, that'd be the way to go, and maybe if value was omitted use
>> System.getenv to get the current value?
MS> Stefan, you're showing your age. That method was deprecated in
MS> JDK1.1. ;-)
I know - I've been there 8^) back in errm.
But there is no alternative that would not be deprecated. Which System
property was supposed to hold the value of my X-Windows DISPLAY
variable, the PID of my SSH agent, ...?
MS> The only difficulty is making the Ant syntax intuitive and
MS> backwardly compatible.
I think Julien's
<exec >
<env key=".." value=".." />
</exec>
is perfectly valid given those constraints. If no env tag has been
specified, no environment variables get passed - that's backward
compatible, isn't it?
Stefan
RE: Controling the environment for exec tasks
Posted by Malcolm Sparks <ma...@iona.com>.
> Yes, that'd be the way to go, and maybe if value was omitted use
> System.getenv to get the current value?
Stefan, you're showing your age. That method was deprecated in JDK1.1.
;-)
The Runtime.exec(String[] cmds, String[] envp) methods works
without the need for scripts. The only difficulty is making the Ant
syntax intuitive and backwardly compatible.
Malcolm
> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@bost.de]
> Sent: 17 July 2000 07:52
> To: ant-dev@jakarta.apache.org
> Subject: Re: Controling the environment for exec tasks
>
>
> >>>>> "JC" == Julien Couvreur <jc...@redcart.com> writes:
>
> JC> <exec ...>
> JC> <env key="k1" value="v1"/>
> JC> <env key="k2" value="v2"/>
> JC> </exec>,
>
> Yes, that'd be the way to go, and maybe if value was omitted use
> System.getenv to get the current value?
>
> JC> but this needs the creation of a new parent class,
>
> No it wouldn't, all you'd need was a createEnv() method in Exec. I'm
> going to think about that when I start to rework the Exec stuff -
> should start with it this week.
>
> JC> And also, I don't know whether Ant support having "env" (or
> JC> "include") called twice this way.
>
> No limits on the multiplicity of nested elements.
>
> Take a look at the modifications I've made to
> docs/index.html#writingowntask and tell me if that makes sense to you
> - and post any corrections please, English is not my native language.
>
> Stefan
>
Re: Controling the environment for exec tasks
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "JC" == Julien Couvreur <jc...@redcart.com> writes:
JC> <exec ...>
JC> <env key="k1" value="v1"/>
JC> <env key="k2" value="v2"/>
JC> </exec>,
Yes, that'd be the way to go, and maybe if value was omitted use
System.getenv to get the current value?
JC> but this needs the creation of a new parent class,
No it wouldn't, all you'd need was a createEnv() method in Exec. I'm
going to think about that when I start to rework the Exec stuff -
should start with it this week.
JC> And also, I don't know whether Ant support having "env" (or
JC> "include") called twice this way.
No limits on the multiplicity of nested elements.
Take a look at the modifications I've made to
docs/index.html#writingowntask and tell me if that makes sense to you
- and post any corrections please, English is not my native language.
Stefan
RE: Controling the environment for exec tasks
Posted by Julien Couvreur <jc...@redcart.com>.
Just a small addition :
If we had a setEnv in Exec.java that instead of
public void setEnv (String env) {
this.env = env;
}
would rather pile up the env string (which should look like "key=value" for
example, as in bash).
So it would look like <exec ..... env="key1=value1" env="key2=value2" />.
First, I don't know if Ant would support having the same "env" key called
twice.
Next, I would look better if it was rather like :
<exec ...>
<env key="k1" value="v1"/>
<env key="k2" value="v2"/>
</exec>, but this needs the creation of a new parent class, like Task and
MatchingTask, and therefore needs to be thought of from the most general
point of view possible. And also, I don't know whether Ant support having
"env" (or "include") called twice this way.
Julien
RE: Controling the environment for exec tasks
Posted by Julien Couvreur <jc...@redcart.com>.
Hi,
So it is possible to tune environment variables before launching a process.
Now comes the question : how could we extend the "exec" task to support
this.
The problem to me is that ANT expects to know the name of the parameters you
can set in a task. Whereas in our case, we don't know them in advance.
That is : somebody may want to set "DISPLAY" and "TERM", while somebody else
needs to change "CLASSPATH".
So it seems a direct use of ANT notation is not enough our case.
I am curious to know what the ANT "gurus" are thinking of this issue. But it
seems to me a feature useful to have in "exec", even though it doesn't seem
immediate to implement.
Julien
RE: Controling the environment for exec tasks
Posted by Malcolm Sparks <ma...@iona.com>.
I was just thinking the same thing. Actually,
java.lang.Runtime's exec method is overloaded
to take a string array with the environment
vars set in name=value syntax. I've used this
before.
Unfortuately, the Exec taskdef doesn't make
use of this facility.
Since many environment variables are pathnames,
it would be very handy if ant used it's
pathname conversion stuff to ensure paths worked
on all platforms.
Malcolm
> -----Original Message-----
> From: Julien Couvreur [mailto:jcouvreur@redcart.com]
> Sent: 14 July 2000 22:30
> To: ant-dev@jakarApache. Org
> Subject: Controling the environment for exec tasks
>
>
>
> Hi,
>
> Somebody posted a message saying what he greatly enjoyed with Ant was the
> possibility of not depending on the system environment (ie CLASSPATH
> especially).
>
> You may want to call third-party scripts from ant, and these may
> (and often)
> need to run in a special environment. So it would be nice if exec could
> specify env variables for the program that we exec.
>
> Unfortunately, maybe Java doesn't support changing environment
> variables (it
> only allows reading, via System.getXxx()). Would there still be a way of
> doing this env variable setting ?
>
>
> Julien Couvreur
> RedCart, Enabling Digital Marketplaces.
> http://www.redcart.com
>