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?

[Semjon]

@Hoff
> 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.

We are open for contributing. And there I meant, once the issue is fixed, we are glad to put necessary changes to our repository.

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

SVN_EDITOR -- default variable used on every platform supported, since it's working on OpenVMS, I'd keep things as they are.

> I'd probably just open a file in the /tmp/filename.txt area and write stuff there (or via the mktemp routines or such)

Here we use approach, which is common for every platform. The only change I'd make is removing dots from the file name as it was suggested later (by generating a random string appended to name).

@H.Becker
Thank you for the script provided.

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

Ok, I logged into deathrow server. But I got problems running 'lse.com' from jsvn. 'lse.com' starts lsedit screen but opens a file, which was last opened by lsedit (not svn-commit.tmp). I suggest, the problem is at
> f=f$search("sys$scratch:''p2'")
line, since "sys$scratch:svn-commit.tmp" cannot be found.

Speaking generally that approach doesn't seem to be reliable, since user can define another temporary directory path. Although it makes sense to put that script to our repository, it will give at least one workaround for the problem.

@ Graham Burley
> 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?

Most likely the working directory is a subversion working copy. If running editor command fails (as we have now), svn-commit.tmp file remains at the working copy, and there is a chance that user will add that file unintentionally. Or status of the working copy will unexpectedly show that file as added. So, I think it's good approach to keep such temporary files out of current directory.

[Hoff]

Your strategy here appears flawed, whether seeking a maintainer, or seeking to provide a connection from SVN to the editor via hackery.

The C code that was referenced earlier does what you requested, both using a spawned subprocess and using the editor directly from within the application via its callable interface. This based on the mapping of tmp and SYS$SCRATCH:; the temporary directory on OpenVMS.

As for a more general approach toward your goal, look first for a maintainer that knows OpenVMS here and not by adding hacks (adding hacks reflects very badly on your package). Also look to discuss options and alternatives over in the PORTING_TO_VMS porting notes conference on decuserve.org. You'll have a better UI and a whole pile of details related to porting Unix software to OpenVMS, and contact with folks that work with that sort of thing.

The Decuserve.org conferences (and there are a number of them available over there) are readable from outside via HTNotes, though you'll need to sign up for a username (free) to post to the conferences.

Direct (anonymous) conference access:

http://decuserve.org/anon/htnotes/conf?f1=PORTING_TO_VMS

If you want to post, sign up for an account by telnet'ing into the box, and following the registration process.

[H.Becker]

Calling an editor via an API (just for VMS) seems ueber-engineered.

There are already
jsvn commit -m "Corrected number of cheese slices."
and
jsvn commit -F cheese-message

On VMS a jsvn user can probably edit such a message file with any editor (maybe one needs to write a stm_lf record format).

If someone wants his favorite editor being called from jsvn to write that message, it seems appropriate to use the SVN_EDITOR variable or the --editor-cmd switch, as is. To get the latter working for a couple of VMS users some hackery seems good enough.

Jsvn is a Java based client for subversion. A VMS native client may implement a better --editor-cmd to run any VMS editor and pass a VMS file specification.