Re: [Oorexx-devel] A potential problem related to the rexximage problem.

Oh, I guess that's only a Windows thing then. :-( On 1/5/2019 5:08 PM, Rick McGuire wrote: On Sat, Jan 5, 2019 at 4:53 PM Gil Barmwater > wrote: Not being a *ix guy, wouldn't the env. var. REXX_HOME give you the path to all of the executables? There

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

Windows != Linux, so no, there has never been a REXX_HOME variable there. Rick On Sat, Jan 5, 2019 at 6:13 PM Jeremy Nicoll wrote: > On Sat, 5 Jan 2019, at 22:08, Rick McGuire wrote: > > > There has never been a REXX_HOME environment variable. > > Yes there has. It got set by the installer

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

On Sat, 5 Jan 2019, at 22:08, Rick McGuire wrote: > There has never been a REXX_HOME environment variable. Yes there has. It got set by the installer (in Windows) - it's mentioned in the installer log file. -- Jeremy Nicoll - my opinions are my own.

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

Not necessary IMO, for the way ooRexx is structured now the ooRexx binary directory MUST be in the PATH Otherwise a generic rexx, would never be able to use rxqueue and rxsubcom Using objects locating them by the relative position might be needed only to Guarantee consistency to the environment

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

On Sat, Jan 5, 2019 at 4:53 PM Gil Barmwater wrote: > Not being a *ix guy, wouldn't the env. var. REXX_HOME give you the path to > all of the executables? > There has never been a REXX_HOME environment variable. Rick > On 1/5/2019 9:17 AM, Rick McGuire wrote: > > Actually, the path we really

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

On Sat, Jan 5, 2019 at 4:54 PM Enrico Sorichetti via Oorexx-devel < oorexx-devel@lists.sourceforge.net> wrote: > > > On 5 Jan 2019, at 22:32, Gil Barmwater wrote: > > Actually, the path we really need is the location of librexxapi. > > > Why ? > Because ooRexx can be used by any application. so

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

> On 5 Jan 2019, at 22:32, Gil Barmwater wrote: > >> Actually, the path we really need is the location of librexxapi. Why ? ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

Not being a *ix guy, wouldn't the env. var. REXX_HOME give you the path to all of the executables? On 1/5/2019 9:17 AM, Rick McGuire wrote: Actually, the path we really need is the location of librexxapi. It looks like dladdr1() might give me the information I want, The main process

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

This link proposes otool -L to find libraries at non-standard locations at runtime https://stackoverflow.com/questions/4513799/how-to-set-the-runtime-path-rpath-of-an-executable-with-gcc-under-mac-osx?rq=1

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

If you were making a lot of calls to external rexx programs, it would try to restart rxapi on every external call. If you tried to use queues at all, you would get an error message. Rick On Sat, Jan 5, 2019 at 10:18 AM Enrico Sorichetti via Oorexx-devel < oorexx-devel@lists.sourceforge.net>

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

Having “.” In the PATH is against any good judgement A CD to the wrong directory might, will certainly open a can of worm The rxapi thing is a pretty murky issue For basic things looks like the is not really needed I moved the rxapi away from the path And a pretty complicated script run

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

Actually, the path we really need is the location of librexxapi. It looks like dladdr1() might give me the information I want, The main process executable might be an app that is just linked to the interpreter (for example bsfoorexx used from java).

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

It would be a lot nicer if there was one standard way to do this :-( Rick On Sat, Jan 5, 2019 at 7:25 AM Enrico Sorichetti via Oorexx-devel < oorexx-devel@lists.sourceforge.net> wrote: > here are three snippets that show how to do it > > APPLE > > #include > #include > #include > #include >

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

here are three snippets that show how to do it APPLE #include #include #include #include #include int main() { pid_t pid; char path[1024]; int RC; char *cp; pid = getpid(); RC = proc_pidpath (pid, path, sizeof(path)); if ( RC <= 0 ) { exit(-1);

[Oorexx-devel] A potential problem related to the rexximage problem.

I found the source of the lingering rexximage processes, but it might have uncovered a potential problem with the new rxapi daemon. On unix-based systems, rxapi is launched by doing a fork() and then calling execvp() to replace the current process image with rxapi, with the rxapi process being