I have more than one office program which runs in OS/2-eCS. I can start them all if I want to.
I have this command file;
@echo off
set LIBPATH=i:\office\OpenOffice4\program;%LIBPATH%
set path=i:\office\OpenOffice4
I:
cd i:\office\OpenOffice4\program
soffice.exe
I get an error which I can't translate into a missing file or so.
A popup appears with the message
return code: 2
failing module:ICUUC42
That's it, end excution and I'm back on the prompt, did start the commandfile in an eCS command session. I played with some set libpath and set path settings, same popup.
I think that a little readme or reados2 or something won't do harm.
Joop, setting a
LIBPATH environment variable doesn't give you anything at all.
If you read your
CONFIG.SYS file, you may notice, that in contrast with the environment variable
PATH, which is set up with a string like this:
SET PATH=C:\OS2; ... ; ... ; ...
,
LIBPATH is
not an environment variable. It is an OS/2 command, that may be executed only during startup (when
CONFIG.SYS gets executed):
LIBPATH=C:\OS2\DLL;.;C:\usr\lib; ... ; ... ; ...
, so setting a
LIBPATH environment variable in your local cmd interpreter environment although doesn't fail, but neither does give you anything useful. It
does not extend your
LIBPATH.
But it is still possible by using
BEGINLIBPATH and
ENDLIBPATH. These are the features of ours OS/2 command interpreter that allows you to make it (the command interpreter) to extend its own
LIBPATH (locally) prepending (
BEGINLIBPATH) or appending (
ENDLIBPATH) new paths to it. When you then start a child process, like a new OS/2 session, or a program (OpenOffice), it
inherits the extended
LIBPATH.
So for your case you should've written:
SET BEGINLIBPATH=I:\office\OpenOffice4
That would work, although
neither BEGINLIBPATH, nor ENDLIBPATH are not environment variables, they are just a way to tell
CMD.EXE to extend its
LIBPATH.
Although now I can't see how can your script help. In
CONFIG.SYS, the global setup of
LIBPATH may contain or not contain a
dot, i. e. the
current working directory. But it is usually there. If you have reasons, you may remove it, but you will usually need to do more work (like writing this script) to start most of the apps. But again, if your global
LIBPATH contains the current working directory, creating a program object is just enough.
You can also extend
LIBPATH using
BEGINLIBPATH (or
ENDLIBPATH) with a dot like Lewis said, but I've read somewhere (can't google it back), that the needed command is not straight-forward
SET BEGINLIBPATH=., but:
SET BEGINLIBPATH=.\.
I can't remember the reasons, but I use
.\., and it works for me, so I recommend using this instead.