It's been a while (like 1997!) since I worked on VMS, and I don't have access to a VMS box right now, but I'd be willing to chip in on the JNI library if that is acceptable.
Downside is that you'll have to ship the VMS shared library, or the ant installation process would need to include the source with instructions on how to compile and link it (or a DCL script to do so).
Just another option...
Ken
At 08:55 AM 7/10/2003, you wrote:
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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
