Operating System - OpenVMS

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

Go to solution
New Member

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

> 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).

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.
Honored Contributor

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

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:


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

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

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

There are already
jsvn commit -m "Corrected number of cheese slices."
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.