AbtProgramStarter and path on Linux

[jtu...@objektfabrik.de]

Dear VAST community,

I seem to be fighting a number of lost fights against the AbtProgramStarter.

Right now I am having problems with the execution environment of an external program on (Ubuntu) Linux. The process I am starting writes output files, but unfortunatley does not accept parameters for setting the names and locatios of the files. So it is important what execution environment is used to start the process in order to look at the result files after the program ran.

Let's call the process pdflatex, just to have a name ;-)

Let's say my image directory is /home/joachim/VAST91x64 and I created a subdirectory there named pdf. I am creating a few input files and put them there and want the process' output to be written there.

So in order to prepare a document, I write a few "input" files (like a Mustache'd .tex file) to that /home/joachim/VAST91x64/pdf and then start pdflatex by using somthing like this:

   tempDir := '/home/joachim/VAST91x64/pdf'.

    starter := AbtProgramStarter new.
    starter programName: 'pdflatex'.  "This is found and executes, but output is written to the wrong path"
    starter programInput: '  -interaction=batchmode "' , tempDir , prozessname , '.tex" '.
    rc := starter startProgram.

The program runs and creates a pdf document and a few other log and auxiliary files. But not in /home/joachim/VAST91x64/pdf. It creates them in the image directory /home/joachim/VAST91x64.

I have tried chdir: to change to the /pdf subdirectory before starting the program, but that changes nothing - the output is always written to the image directory...

Any thoughts?

Joachim

[jtu...@objektfabrik.de]

Hmm, I found a "solution"

I had been using CfsDirectoryDescriptor chdir: in order to change the directory before starting the process, but it seems that is not affecting the shel environment in which the process is actually started.

What does work, however, is this:

starter := AbtProgramStarter new.
    starter programName: 'cd ./pdf; pdflatex'.
    starter programInput: '  -jobname=',prozessname, ' -interaction=batchmode "' , tempDir , prozessname , '.tex" '.

    rc := starter startProgram.

Although it works, I don't actually like this very much. for one, it may not be portable to Windows (where I don't have that problem, btw., but other issues). The other thing is that I think this should be a parameter of the program starter.

So I think I will end up writing a wrapper around the program starter to flatten out some of the platform differences...

Did others have this issue? How did you solve it?

Joachim

[Norbert Schlemmer]

Hello Joachim

Although it works, I don't actually like this very much. for one, it may not be portable to Windows (where I don't have that problem, btw., but other issues). The other thing is that I think this should be a parameter of the program starter.

..other issues with Windows ? Which one ?

We are using the program starter under Windows without troubles.

Norbert

[Joachim Tuchel]

Hi Norbert,

well, the issue is not so much that it doesn't work on windows, it's more a question of how much different it is from Linux. Like the return code being a Boolean, while it is a Process instance on Linux. These differences make life a bit hard for cross-platform work...

It does work and start external programs, so it does its job as specified.

I should better say I find a few things very desirable for AbtProgramStarter, like listening to stdout and stderr, choosing to either wait for the external program or not, a cross-platform-API, and so on. One of my issues on Windows is that pdflatex takes forever to finish on Windows and is just done in the blink of an eye on Linux, and since you cannot wait for the return code nor have a handle to the external process (PID or such),  there is a need for polling for the output file and doing annoying stuff that is not necessary on Linux...

Joachim