Java: Runtime#exec lsedit "/tmp/file/path" fails.

[Semjon]

Hello,

I'm working on SVNKit -- pure Java SVN implementation.

Some time ago we got a bug report always reproducible on OpenVMS alpha server, you can find it at http://svnkit.com/tracker/view.php?id=324.

The problem is that we execute the following command:
lsedit /SYS$SCRATCH/svn-commit.1.tmp
which fails due to malformed pathspec.

AFAIU such path was builded as a result of Unix-VMS pathspec mapping. Description of that mapping I found here -- http://h18000.www1.hp.com/java/documentation/1.4.2/ovms/docs/user_guide.html#unix_style

On one hand we need that mapping since we read from/write to the file, on the other hand we have to put correct path to lsedit parameters.

So, did anyone here get the same problem, is there any workaround for the issue?

Thanks in advance!
-- Semjon.

[Hoff · Accepted solution]

The bug report points to a terminal device or to run-time terminal environment setting needed for the text editor, and the ensuing discussions of temporary paths seems unrelated.

Here? Run a JNI call into the editor and see how far you get; the entry points here are LSE$LSE and LSE$EDIT.

Details:

http://h71000.www7.hp.com/doc/82final/decset/6355_pro.pdf

And if you want to pass file specifications to LSEDIT or most anything else on OpenVMS (outside of the GNV environment and commands), then you need to convert to and use OpenVMS specifications.

[Hoff]

ps: all that mapping stuff and path-building stuff? That's not relevant here . That is intended to allow a C, C++ or Java application to traverse into and access files within the OpenVMS environment. That path-mapping stuff does not allow an OpenVMS command to operate. Native OpenVMS applications and utilities know nothing of all that mapping stuff.

[Richard Brodie_1]

I would just push the responsibility for fixing up the path to the external editor command, and document that.

A few lines of C and a call to decc$to_vms should do the trick. Maybe someone will be kind of to post some example code.

Otherwise, you would be hand-mangling the paths in Java with string manipulation, which is ugly and fragile.

[H.Becker]

You may want to

$ DEFINE JAVA$EXEC_TRACE TRUE

before starting Java and see what execvp() gets as arguments.

As mentioned in a few other entries in this forum, you can not pass a DCL verb to execvp, you can only pass executables and command files.

That is, you need to start /sys$system/lsedit.exe But that only works if LSE can be started with "mc lsedit".

So you may want to create a command file to start LSE.

It depends on your java code, where the input and output go to. They are likely redirected (to VMS mailboxes). You may want to define LSE$DISPLAY_MANAGER as DECWINDOWS and that may get you an input and output devices to work with LSE.

That leaves you with the Unix file spec. You can play with the ^UP^ prefix. On recent versions and FTs of VMS hat should work with logicals like sys$scratch or with a directory sys$scratch in the Posix root. (SET/SHOW ROOT). Before passing that to Java I would try that on the command line.$ dir "^UP^/sys$scratch/*.*". Or you can put some name translation code in the command file.

Seems a lot of work/hacks to me to get it work.

[Hoff]

Here's an example of the decc$to_vm routine:

http://www.mpp.mpg.de/~huber/util/main/unix_to_vms.C

This is (inexplicably) one of the most complex APIs available in C.

[Semjon]

Hello,

Unfortunately I'm not experienced OpenVMS user, and I have no OpenVMS machine available. So far I put a link to this discussion at our bug tracker to let user get overview of the problem.

The following workaround seems to be good for me:
1. User creates a command file, which is responsible for converting Unix-style path to OpenVMS specification and for running 'lsedit' executable.
2. Specifies SVN_EDITOR variable to use that new command file.

Here is what should happen (schematically):
1. File tmpFile = new File(tmpDir, "svn-commit.1.tmp").
2. Write initial data to tmpFile.
3. String editorCmd = getProperty("SVN_EDITOR")
4. Runtime#exec(editorCmd, tmpFile.getAbsolutePath())
5. Command file executed, /SYS$SCRATCH/svn-commit.1.tmp passed as a parameter to it.
6. Command file converts "/SYS$SCRATCH/svn-commit.1.tmp" to "SYS$SCRACTH:svn-commit.1.tmp" and executes "sys$system:lsedit.exe SYS$SCRACTH:svn-commit.1.tmp".
7. lsedit exists, command file exits. We get commit message available from tmpFile.

Correct me please, if I'm mistaken.

And thanks a lot for your prompt replies!

[Hoff]

>Unfortunately I'm not experienced OpenVMS user, and I have no OpenVMS machine available.

That would likely be incorrect; you probably do have access to OpenVMS systems. Here are two:

telnet deathrow.vistech.net

telnet decuserve.org

Sign up for a free account.

>1. User creates a command file, which is responsible for converting Unix-style path to OpenVMS specification and for running 'lsedit' executable.

Tossing this task off onto the end-users means everybody gets to fix this all over the place. That's not really a solution. That's something approaching chaos.

>2. Specifies SVN_EDITOR variable to use that new command file.

There are already mechanisms in OpenVMS for this, including callable APIs embedded within the editors.

Here, that "variable" would be a logical name that specifies the editor, as well. Or an option in a configuration file. There are other ways...

In general, this is an area that works entirely different from Unix, too. Various tools on OpenVMS (including editors) can be invoked under program control. Pulling a Unix solution directly over probably won't make anybody happy, either.

>Here is what should happen (schematically):
1. File tmpFile = new File(tmpDir, "svn-commit.1.tmp").
2. Write initial data to tmpFile.
3. String editorCmd = getProperty("SVN_EDITOR")
4. Runtime#exec(editorCmd, tmpFile.getAbsolutePath())
5. Command file executed, /SYS$SCRATCH/svn-commit.1.tmp passed as a parameter to it.
6. Command file converts "/SYS$SCRATCH/svn-commit.1.tmp" to "SYS$SCRACTH:svn-commit.1.tmp" and executes "sys$system:lsedit.exe SYS$SCRACTH:svn-commit.1.tmp".
7. lsedit exists, command file exits. We get commit message available from tmpFile.

>Correct me please, if I'm mistaken.

That looks like real work.

I'd probably just open a file in the /tmp/filename.txt area and write stuff there (or via the mktemp routines or such), and then invoke the editor against the file in SYS$SCRATCH:filename.txt via spawn or (more elegantly) via the callable API. tmp maps to SYS$SCRATCH.

Here's an example of both the callable API and the approach using a DCL command and the lib$spawn operation:

http://labs.hoffmanlabs.com/node/1447

[H.Becker]

Hack alert, create

$! file: lse.com
$ set proc/parse=ext
$ define sys$input 'f$log("tt")
$ define sys$output 'f$log("tt")
$ define sys$error 'f$log("tt")
$ p2= p2-"/SYS$SCRATCH/"
$ f=f$search("sys$scratch:''p2'")
$ define/user sys$command 'f$log("tt")
$ lse 'f

Make sure there is no file SYS$SCRATCH:svn-commit*.tmp.

And then try

$ jsvn ci --editor-cmd ./lse.com

jsvn creates temporary commit files svn-commit.tmp and if that exists svn-commit.1.tmp and if that exists svn-commit.2.tmp and ...
On VMS these files can end up as SVN-COMMIT.TMP, SVN-COMMIT_1.TMP, SVN-COMMIT_2.TMP

While testing this I couldn't convince JSVN (Java?) to create the dot in the name. P2 (yes, P2!) contains the filename as "/SYS$SCRATCH/svn-commit.1.tmp". That is not easy to match with SVN-COMMIT_2.TMP.

Good luck.

PS: For testing you may want the commit, that is the lse.com to fail, an appended "$ exit 42" comes handy.

[Graham Burley]

Taking a step backwards, it's not obvious to me why you need to specify a full path to the temporary file at all. If the software isn't changing it's default/current/working directory all over the place why not just create and edit the file wherever the default/current directory happens to be?