Tunneling Between Windows and Unix

[rschoen]

We are migrating from Arbortext 5.3 for Unix to Arbortext 6.0 for Windows. All of our content will stay on our Unix file system. We have many customizations which call perl and shell scripts on the Unix system. From the Arbortext 6.0 installation, I have figured out how to run these scripts using PuTTY to generate a tunnel to the Unix server. How do I grab the output of one of these scripts to insert that data back into the XML file I am working on? For example, one of the scripts in question, uses the name of the journal and the manuscript id number to query our database for the DOI of the manuscript in question. In Arbortext for Unix we would assign a local variable as follows:
local return_value = `${codepath}/jpubs_get_doi_from_msid.pl ${journal} ${msid}`
The return_value is the result of running the perl script which in this case would be the DOI from the database.

In Arbortext for Windows, I have to do this as a system call:
local return_value = system("plink -ssh -i \"C:\Program Files (x86)\PuTTY\${user}.ppk\" $user@ucp-jrnls-cpt1.uchicago.edu ${codepath}/jpubs_get_doi_from_msid.pl ${develop_flag} ${ms_journal} ${ms_msid}" )
The return_value here is the exit status of the system call not of the running of the perl script. When the perl script finishes running a command window containing the result of the script (i.e., the DOI of the article in question) flashes on screen for a second. Does anyone know if there is some way to capture this result as an Arbortext variable so I can insert the value into my XML file?

I'd appreciate any suggestions.

Thanks,
Rick

[ClayHelberg]

Hi Rick--

The easiest thing, I think, will be to redirect your output to a file (on UNIX) and then read the contents of the file from your Arbortext script, something like this:

local return_value = system("plink -ssh -i \"C:\Program Files (x86)\PuTTY\${user}.ppk\" $user@ucp-jrnls-cpt1.uchicago.edu<">mailto:$user@ucp-jrnls-cpt1.uchicago.edu> ${codepath}/jpubs_get_doi_from_msid.pl ${develop_flag} ${ms_journal} ${ms_msid} > /local/tmp/output.txt " )
$output = ";
$outputfile = open("file://ucp-jrnls-cpt1.uchicago.edu/local/tmp/output.txt", "r");
while (getline($outputfile,$line)!=0) {
$output = $output . " " . $line;
}
close($outputfile);

You would need to make sure the temp file gets written to a location that is accessible from Arbortext over the network, and you would probably want to delete it when you're done with the task.

If you do this a lot, it might be worth putting it into a function in your init.acl file, so you can just pass in the command string and get the result back without having to put all this stuff inline.

--Clay

[jonathan.reeve]

I think that Putty will only display the output in its own terminal window. One solution is the sort of thing that Clay Helberg suggested. Another is to run the perl and shell scripts on Windows. You can do this if you install Cygwin. Then the script output is available in exactly the same way as if you ran any other Windows command line tool.

Even if you still want to run the scripts on the Unix server, you can call them locally with Cygwin's ssh command, something like this:

ssh username@hostname "scriptname arguments"

The output from the local ssh command is the output from the remote script.

[GarethOakes]

Sorry to butt in here, but it occurs to me that it may be an architecturally nice method to have the Unix side present its functionality as some sort of services API or service bus. That way you can separate the shell scripty stuff from the Arbortext GUI/ACL, and have it all work neatly in a remote fashion. Maintainable, flexible, etc.

That may be overkill for this situation but thought I’d throw that out there as an idea, or in case it sparks other ideas. Something like a JSON-RPC, XML-RPC or Apache Wink may be useful as a services provider.

Gareth Oakes
Chief Architect, GPSL
www.gpslsolutions.com

[rschoen]

Clay,

Thanks for that suggestion. Your solution worked beautifully. I did create a function for this and now have to apply it throughout our tool set.

Thanks again for your help and Happy Holidays!

Rick