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
