ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <knut.wannhe...@paranor.ch>
Subject RE: <exec> on openvms
Date Thu, 10 Jul 2003 12:55:24 GMT
Stefan,

> 
> > I think it should all be solvable inside Execute.  You could
> > restrict users to only execute .EXE and .COM files on VMS.  Another
> > solution is to write the command to a temporary .COM and then
> > execute that.  But I have to do some more testing here.
> 
> In either case, we should add some platform specific notes into the
> Ant manual.
> 

Certainly, yes.

> > The Runtime.exec() with working directory *does* work in more recent
> > versions of the JVM (1.3.1-6 and up) given that a special symbol has
> > been defined.
> 
> Do you think we have a chance to tell a VM that works from one that
> doesn't within Execute?  I mean, we always could use reflection to
> detect the three arg version of exec, but maybe there is an easier
> way.
> 

Well, the three arg version (with a specified working directory) is always
present, but it only works if the logical JAVA$FORK_SUPPORT_CHDIR is defined
in the job table, i.e. if prior to launching Java the following has been
done:

	$ define/job JAVA$FORK_SUPPORT_CHDIR TRUE

So it's not only a matter of the VM, unfortunately.  But the other
Runtime.exec() methods (without working directory) should all work.  If the
logical isn't defined, Runtime.exec() will return with an IOException with a
message like "function not implemented".

I assume it will be necessary to implement a VMS specific CommandLauncher
for launching through the shell.  I'll have to check how to do that.  Its
implementation could for instance write a temporary DCL script (.COM file)
and execute the command through that.

It would also be interesting whether it's possible to get a list of all
defined logicals (for <property environment="env"/>).  This would probably
again require writing and executing a temporary .COM file.

Also, I currently don't know what the VM does with environment variables
passed to Runtime.exec().  I'll try to find out.

> Expect Os.isFamily("openvms") to work in a few minutes 8-).
> 

Great!

> >> >  - The Ant <exec> task throws a BuildException if the exit code
> >> >  is unequal zero.
> > 
> > Do you know how to get around that?  Should the Execute class, in
> > the case of VMS, map the exit status to what's common on Unix
> > systems?
> 
> Maybe we should provide a Execute.isFailure(int result) method that 
> returns result != 0 on all platforms except OpenVMS (and 
> result % 2 != 0 on OpenVMS).
> 
> > Or would ExecTask need some modifications?
> 
> To accompany that, yes.  I'd prefer to keep the platform specific code
> isolated in Execute.
> 

That sounds like a very clean approach.  There seem to be some other tasks
which check the return value of Execute#execute() against zero though,
including <cvs>, <cvstagdiff>, <cvschangelog>, and <javadoc>.  Would
this
change be a backward compatibility issue?

Once I have gathered all the information I'll try to write a patch for
Execute to get <exec> and friends to work on VMS.

--
knut

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message