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'.
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 sundirectory before starting the program, but that changes nothing.
So I decided to put on my debugger belt and watch what happens. I am not sure I found a hint of what is exactly wring, but some things seem to be wrong anyways, maybe even related.
One thing I found is that AbtProgramStarter>>#runCshCmd: checks for hard coded paths and environment variable names that are correct for AIX, but not Linux:
Let's take a look:
"Invoke a C shell which executes aString in the current environment, but with
any reference to /usr/lib/threads stripped from LIBPATH (for AIX).
Block the invoking Smalltalk process until the OS process completes, so that
we can capture and return the OS process exit status.
Answer the integer exitCode of the OS process.
If an error occurs starting the process, answer nil. "
| execEnv process libpath |
execEnv := (libpath := UNIXEnvironment current at: 'LIBPATH') isNil
ifTrue: [UNIXEnvironment current]
zork := '/usr/lib/threads'.
0 = (libpath indexOfSubCollection: zork startingAt: 1)
ifTrue: [UNIXEnvironment current]
ifFalse: [|newpath newenv|
newpath := ''.
(libpath abrSubstrings: $:) do: [:ea|
0 = (ea indexOfSubCollection: zork startingAt: 1)
ifTrue: [newpath := newpath, ea, ':']].
newenv := UNIXEnvironment current keys
inject: UNIXEnvironment new
into: [:env :key| env
at: key put: (UNIXEnvironment current at: key);
newenv at: 'LIBPATH' put: newpath; yourself]].
process := UNIXProcess
process isNil ifTrue: [^nil].
[process isComplete] whileFalse: .
I think asking for LIBPATH is not what we really want on Linux. I think we need to ask for LD_LIBRARY_PATH instead. Since the method dates back to 1997, I guess IBM never cared about Linux back then, but I wonder if this code has ever worked on Solaris (LD_LIBRARY_PATH) or HP-UX (SHLIBPATH).... (Take a look here: https://gerardnico.com/os/linux/ld_library_path)
I am not a Linux expert, but what I see is that /usr/lib/threads is not in my LD_LIBRARY_PATH on Linux, so most of this method is not executed on Linux.
I don't have enough Linux knowlege to tell if this is teh reason for my problem, but this seems to need work for Linux.
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/184ef126-785d-4f7f-b4af-71cffc6941d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
|Free forum by Nabble||Edit this page|