#736 Add an install location method to the RexxInfo class

[Rick McGuire]

Since the interpreter now has code to determine the install location for finding the rexx.img file, it would be nice if the interpreter had a method on RexxInfo to return the base install directory. This would be handy, for example, in RexxTry.rex, which currently relies on a REXX_HOME environment variable to locate help information. A method such as this could eliminate that dependency.

[Erich]

Knowing the ooRexx base directory would also come handy for tests that want to run the currently running Rexx interpreter as an external command.

SysProcess::getExecutableLocation() returns the location of the rexxapi shared resource (we really require the location rexx.img, but rexxapi is easier to locate)

On Windows the rexxapi shared resource is rexxapi.dll and its location matches the location of rexx.exe and the value of the current REXX_HOME environment variable.
On Linux it is librexxapi.so and for a default build the location returned is /usr/bin/../lib/ but the ooRexx executable can only be found at /usr/bin/rexx

So, what exactly should a new .RexxInfo~rexxDirectory method return on non-Windows systems?

[Rick McGuire]

I was thinking it should return the root of the install location, so on
non-Windows platforms the /lib portion should be removed.

On Sun, Feb 10, 2019 at 7:20 AM Erich erich_st@users.sourceforge.net
wrote:

Knowing the ooRexx base directory would also come handy for tests that
want to run the currently running Rexx interpreter as an external command.

SysProcess::getExecutableLocation() returns the location of the rexxapi
shared resource (we really require the location rexx.img, but rexxapi is
easier to locate)

On Windows the rexxapi shared resource is rexxapi.dll and its location
matches the location of rexx.exe and the value of the current REXX_HOME
environment variable.
On Linux it is librexxapi.so and for a default build the location returned
is /usr/bin/../lib/ but the ooRexx executable can only be found at
/usr/bin/rexx

So, what exactly should a new .RexxInfo~rexxDirectory method return on
non-Windows systems?

---

[feature-requests:#736] Add an install location method to the RexxInfo
class

Status: unread
Milestone: None
Created: Fri Feb 08, 2019 01:43 PM UTC by Rick McGuire
Last Updated: Fri Feb 08, 2019 01:43 PM UTC
Owner: nobody

Since the interpreter now has code to determine the install location for
finding the rexx.img file, it would be nice if the interpreter had a method
on RexxInfo to return the base install directory. This would be handy, for
example, in RexxTry.rex, which currently relies on a REXX_HOME environment
variable to locate help information. A method such as this could eliminate
that dependency.

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/oorexx/feature-requests/736/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[Rony G. Flatscher]

Would it be possible to have two entries: one for the currently running rexx executable and one for its library location?
E.g. something like the following if executing rexx from a non-installaiton directory with the path "/home/rgf/uninstalled/myrexx5.0.0/bin/rexx myrexxpgm.rex":

say .rexxInfo~rexxhome /* yields: "/home/rgf/uninstalled/myrexx5.0.0" */ 
say .rexxInfo~rexxexe /* yields: "/home/rgf/uninstalled/myrexx5.0.0/bin" */ 
say .rexxInfo~rexxlib /* yields: "/home/rgf/uninstalled/myrexx5.0.0/lib" */ 

In the Windows case "rexxhome", "rexxexe" and "rexxlib" would probably point to the same directory.

[Rick McGuire]

On Sun, Feb 10, 2019 at 9:47 AM Rony G. Flatscher orexx@users.sourceforge.net wrote:

Would it be possible to have two entries: one for the currently running
rexx executable and one for its library location?
E.g. something like the following if executing rexx from a
non-installaiton directory with the path
"/home/rgf/uninstalled/myrexx5.0.0/bin/rexx myrexxpgm.rex":

No, because the interpreter does not know what executable invoked it, and
indeed, it need not be one of the ooRexx launchers, but could be something
like THE or BSFooRexx.

Rick

~~~
say .rexxInfo~rexxhome / yields: "/home/rgf/uninstalled/myrexx5.0.0" /
say .rexxInfo~rexxexe / yields: "/home/rgf/uninstalled/myrexx5.0.0/bin"
/
say .rexxInfo~rexxlib / yields: "/home/rgf/uninstalled/myrexx5.0.0/lib"
/
~~~

In the Windows case "rexxhome", "rexxexe" and "rexxlib" would probably
point to the same directory.

---

[feature-requests:#736] Add an install location method to the RexxInfo
class

Status: unread
Milestone: None
Created: Fri Feb 08, 2019 01:43 PM UTC by Rick McGuire
Last Updated: Sun Feb 10, 2019 12:20 PM UTC
Owner: nobody

Since the interpreter now has code to determine the install location for
finding the rexx.img file, it would be nice if the interpreter had a method
on RexxInfo to return the base install directory. This would be handy, for
example, in RexxTry.rex, which currently relies on a REXX_HOME environment
variable to locate help information. A method such as this could eliminate
that dependency.

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/oorexx/feature-requests/736/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[Rony G. Flatscher]

Sorry should have read: "three entries".

[Erich]

on non-Windows platforms the /lib portion should be removed

Would that result in /usr/bin/../ or /usr/bin/ ?

I just checked on our CentOS slave: SysProcess::getExecutableLocation() returns just /lib64/
(here /lib64 is a link to /usr/lib64)

[Rick McGuire]

I think you just answered one question I had about dladdr()...whether it returned the real location or the link name if that was used. The directory we should return should be the root install location for all of the files, not the link location. SysProcess::getExecutableLocation() should probably dereference any links to get to the real location. I suspect CentOS is probably not locating rexx.img at the location /lib64 using that location.

[Erich]

This patch provides functions getLibraryLocation() and getExecutableLocation() where the first returns the path to the Rexx shared libraries (where also rexx.img is found) and the latter returns the path to the currently running executable. It also adds RexxInfo methods libraryPath() and binaryPath() returning the same info.
While there may well be cases where the currently running executable is not rexx.exe, for the typically case this should still be useful for a) Rexx itself as it can make sure it finds the correct rxapi executable (if none is running) and b) Rexx code which wants to start again the same rexx executable as the one currently running (our test cases frequently do that)

[Rick McGuire]

I'm not sure this patch really works for returning an install location. It
is assuming that the executable is one of ours, but that is not a valid
assumption. For example, a rexx program invoked by bsfrexx would end up
returning the location of the java executable, not rexx. Similar problems
with, for example, THE. I suspect the best we can really do is assume a
directory structure for the different platforms and use that to return a
location relative to the library locations.

Rick

On Wed, Feb 27, 2019 at 5:12 PM Erich erich_st@users.sourceforge.net
wrote:

This patch provides functions getLibraryLocation() and
getExecutableLocation() where the first returns the path to the Rexx
shared libraries (where also rexx.img is found) and the latter returns
the path to the currently running executable. It also adds RexxInfo
methods libraryPath() and binaryPath() returning the same info.
While there may well be cases where the currently running executable is
not rexx.exe, for the typically case this should still be useful for a)
Rexx itself as it can make sure it finds the correct rxapi executable (if
none is running) and b) Rexx code which wants to start again the same rexx
executable as the one currently running (our test cases frequently do that)

Attachments:

• RexxInfo_paths.patch
  (18.1 kB; application/octet-stream)

---

[feature-requests:#736] Add an install location method to the RexxInfo
class

Status: unread
Milestone: None
Created: Fri Feb 08, 2019 01:43 PM UTC by Rick McGuire
Last Updated: Sun Feb 10, 2019 08:35 PM UTC
Owner: nobody

Since the interpreter now has code to determine the install location for
finding the rexx.img file, it would be nice if the interpreter had a method
on RexxInfo to return the base install directory. This would be handy, for
example, in RexxTry.rex, which currently relies on a REXX_HOME environment
variable to locate help information. A method such as this could eliminate
that dependency.

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/oorexx/feature-requests/736/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[Erich]

assume a directory structure for the different platforms

I agree.
To locate rxapi this is reworked to use libraryLocation for Windows and libraryLocation/../bin for Unix.

Commit [r11829] adds a RexxInfo libraryPath() method.
Not used internally, but for other miscellaneous uses a method executable() is added, returning the full path and file name of the current executable (which as discussed might be non-Rexx like Bsf4ooRexx or THE).

OK .... seems I haven't read the title carefully enough. This RFE is about an install location method. It seems, this will again need some rework ..

[Rony G. Flatscher]

The full path to the executable would be very helpful for setup, debug and troubleshooting scripts!

E.g. in the case of BSF4ooRexx the executable could be "rexx[.exe]", "java[.exe]", but also "soffice[.exe]".

In the case of "java[.exe]" starting with Java 9 (introduction of the module system) it has become possible to create "tailor-suited" java-runtime environment such that it is quite likely that there are multiple "java[.exe]" on the system and also, that BSF4ooRexx may be employed by some of them.

Therefore it would be really be very helpful to learn the full path to the executable which includes also the name of the exectuable itself!

[Rony G. Flatscher]

Peeking and testing the entry ".rexxinfo~executable" will already return the fully qualified path to the executable that invoked Rexx, which is really great!

Here the results with the 32-bit Windows of ooRexx when Rexx was invoked via "rexx.exe", via "java.exe" (32-bit) and via OpenOffice (32-bit):

C:\Program Files (x86)\ooRexx\rexx.exe

C:\Program Files (x86)\Java\jre1.8.0_171\bin\java.exe

C:\Program Files (x86)\OpenOffice 4\program\soffice.bin

(OpenOffice/LibreOffice implements a Java scripting framework, such that OOo will load Java which will load BSF4ooRexx which loads Rexx.)

[Erich]

Added rexxref documentation with revision [r11945].

[Erich]

seems I haven't read the title carefully enough. This RFE is about an install location method

As the two new RexxInfo methods executable and libraryPath described above did NOT implement what Rick's initial request was asking for, I've opened a separate [feature-requests:#790] "Add methods to RexxInfo for the current executable and libraries" for these two new RexxInfo methods.

Sorry for missing the point.

I've set this request back to open.