Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

On Thu, Dec 27, 2018 at 2:22 PM Erich Steinböck 
wrote:

> go ahead and make the changes and commit
>
> Committed revision 11649 (for Unix-like systems only)
> This now uses the username in the service/lock file path.
> Uses XDG_RUNTIME_DIR or /tmp, but never ~
> rxapi now prints to the stdout
>
> There's one thing about rxapi: I don't see what we try to achieve with the
> `sigaction(SIGTERM, , NULL)` section.
> I don't see any way rxapi could end gracefully.  If stopped by whatever
> signal it just ends immediately.
>

I just kept what was there originally. Perhaps there was some requirement
for this to run as a system daemon, which makes that a bit obsolete. If
there is a better way to handle this, go for it.

Rick

>
>
> On Thu, Dec 27, 2018 at 11:48 AM Rick McGuire 
> wrote:
>
>> Since it runs in a different process in normal operation, we could
>> probably just unconditionally put out some messages indicating the source
>> of the problem. Then if someone appears to be having issues, we can just
>> ask them to start it from the command line and report the errors.
>>
>> But yes, go ahead and make the changes and commit.
>>
>> Rick
>>
>> On Thu, Dec 27, 2018 at 4:16 AM Erich Steinböck <
>> erich.steinbo...@gmail.com> wrote:
>>
>>> Have you done anything else with these changes?

>>>
>>> Not yet.  I can do the change to use getpwuid() and commit, if you agree.
>>>
>>> What do you think regarding finding out whether rxapi runs or why it
>>> couldn't start?  Maybe add an option to the rxapi command?
>>> This would help (us) with support requests like "Rexx queuing doesn't
>>> work for me -- why?"
>>>
>> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Erich Steinböck]

>
> go ahead and make the changes and commit

Committed revision 11649 (for Unix-like systems only)
This now uses the username in the service/lock file path.
Uses XDG_RUNTIME_DIR or /tmp, but never ~
rxapi now prints to the stdout

There's one thing about rxapi: I don't see what we try to achieve with
the `sigaction(SIGTERM,
, NULL)` section.
I don't see any way rxapi could end gracefully.  If stopped by whatever
signal it just ends immediately.


On Thu, Dec 27, 2018 at 11:48 AM Rick McGuire  wrote:

> Since it runs in a different process in normal operation, we could
> probably just unconditionally put out some messages indicating the source
> of the problem. Then if someone appears to be having issues, we can just
> ask them to start it from the command line and report the errors.
>
> But yes, go ahead and make the changes and commit.
>
> Rick
>
> On Thu, Dec 27, 2018 at 4:16 AM Erich Steinböck <
> erich.steinbo...@gmail.com> wrote:
>
>> Have you done anything else with these changes?
>>>
>>
>> Not yet.  I can do the change to use getpwuid() and commit, if you agree.
>>
>> What do you think regarding finding out whether rxapi runs or why it
>> couldn't start?  Maybe add an option to the rxapi command?
>> This would help (us) with support requests like "Rexx queuing doesn't
>> work for me -- why?"
>>
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

Since it runs in a different process in normal operation, we could probably
just unconditionally put out some messages indicating the source of the
problem. Then if someone appears to be having issues, we can just ask them
to start it from the command line and report the errors.

But yes, go ahead and make the changes and commit.

Rick

On Thu, Dec 27, 2018 at 4:16 AM Erich Steinböck 
wrote:

> Have you done anything else with these changes?
>>
>
> Not yet.  I can do the change to use getpwuid() and commit, if you agree.
>
> What do you think regarding finding out whether rxapi runs or why it
> couldn't start?  Maybe add an option to the rxapi command?
> This would help (us) with support requests like "Rexx queuing doesn't work
> for me -- why?"
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Erich Steinböck]

>
> Have you done anything else with these changes?
>

Not yet.  I can do the change to use getpwuid() and commit, if you agree.

What do you think regarding finding out whether rxapi runs or why it
couldn't start?  Maybe add an option to the rxapi command?
This would help (us) with support requests like "Rexx queuing doesn't work
for me -- why?"
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

Have you done anything else with these changes?

Rick

On Mon, Dec 24, 2018 at 6:40 PM Erich Steinböck 
wrote:

> With a few typos fixed, this seems to work as expected, also in the
> discussed sudo scenario.
>
> also includes the login name in the file names
>>
> getuid() returns the id, not the name, so I had changed the %s to %d in
> the snprintf's
> I assume getting the name will require getpwuid() - if we want the name
> instead
>
> If no XDG_RUNTIME_DIR is set, this will be something like:
> ls -lda /tmp/.ooR*
> -rw-rw-rw- 1 jenkins  jenkins  0 Dec 24 23:19
> /tmp/.ooRexx-5.0.0-64-1002.lock
> srwxrwxrwx 1 jenkins  jenkins  0 Dec 24 23:49
> /tmp/.ooRexx-5.0.0-64-1002.service
> -rw-rw-rw- 1 www-data www-data 0 Dec 24 23:52 /tmp/.ooRexx-5.0.0-64-33.lock
> srwxrwxrwx 1 www-data www-data 0 Dec 24 23:49
> /tmp/.ooRexx-5.0.0-64-33.service
> I'm a bit concerned about the file permissions global RW bits, but to my
> surprise rm nevertheless refuses to remove both the lock and the service
> "file" (rm: cannot remove '/tmp/.ooRexx-5.0.0-64-1002.lock': Operation not
> permitted .. I don't understand why)
>
> There is one situation that will make rxapi fail to start: if a malicious
> user creates a simple file with the same name as the lock/service file of a
> user.  It might still be a good idea to check whether rxapi can create
> those files (XDG or /tmp) and if not, somehow (but how?) give an error
> indication "cannot create path/.ooRexx...service"
>
> On Mon, Dec 24, 2018 at 2:19 PM Rick McGuire 
> wrote:
>
>> Ok, from what Bob Martin posted, it sounds like the www-data login does
>> not have XDG variables set and also does not have write access to the home
>> directory. As others have said, using the home directory is probably a bad
>> idea because it could be network-mounted and using it would lock out users
>> on other machines. Here is a totally uncompiled and untested patch that
>> uses either the XDG_RUNTIME_DIR or /tmp for creating the files and also
>> includes the login name in the file names.
>>
>> Rick
>>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[P.O. Jonsson]

This is what is a bit weird: I deleted the old ooRexx installation (from /opt 
or /uer/local) on the 4th of december, at 22:00 sometime (I checked the garbage 
bin), hence there was no ooRexx installation available on the user „po“ on that 
machine at the 8.12. entering „rexx“ on the command line give „command not 
found"

I have deleted both files, If they resurface I will let you know.

Von meinen Macbook gesendet

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



> Am 25.12.2018 um 12:35 schrieb Rick McGuire :
> 
> You probably ran ooRexx back on December 8th, which is when they were 
> created. You can delete them, but the files will get recreated the next time 
> you run ooRexx. 
> 
> Rick
> 
> On Tue, Dec 25, 2018 at 6:25 AM P.O. Jonsson  > wrote:
> I have no recollection of having made a build on that userID for quite some 
> time, hence the question,, it is Erich that uses the „Jenkins“ account on the 
> same machine to make the automated builds, hence the question.
> 
> Here are the further details of these files
> 
> -rw-rw-rw-   1 postaff  0 Dec  8 16:19 .ooRexx-5.0.0-64.lock
> srwxrwxrwx   1 postaff  0 Dec  8 16:19 .ooRexx-5.0.0-64.service
> 
> I assume I can safely delete them?
> 
> Von meinen Macbook gesendet
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
> 
> 
>> Am 25.12.2018 um 11:42 schrieb Rick McGuire > >:
>> 
>> If the build was running under your userid, that file got created when rxapi 
>> was launched during the build process. That's the file that is used to 
>> ensure that only one copy of rxapi runs per user. 
>> 
>> Rick
>> 
>> On Tue, Dec 25, 2018 at 5:09 AM P.O. Jonsson > > wrote:
>> Dear Erich,
>> 
>> I was going into my user account on the Mac Mini Jenkins slave today and 
>> noticed a hidden file ".ooRexx-5.0.0-64.lock“ in my home directory 
>> (Users/po) Is this something that is coming out of the Jenkins build? How 
>> can the lock file be in my account? I have no ooRexx installation in that 
>> account and the machine wide installation has been removed. some time ago.
>> 
>> Can you please explain the latest development with the locking and how it is 
>> intended to work? No criticism, just trying to understand. 
>> 
>> Von meinen Macbook gesendet
>> 
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se 
>> 
>>> Am 25.12.2018 um 00:39 schrieb Erich Steinböck >> >:
>>> 
>>> With a few typos fixed, this seems to work as expected, also in the 
>>> discussed sudo scenario.
>>> 
>>> also includes the login name in the file names
>>> getuid() returns the id, not the name, so I had changed the %s to %d in the 
>>> snprintf's
>>> I assume getting the name will require getpwuid() - if we want the name 
>>> instead
>>> 
>>> If no XDG_RUNTIME_DIR is set, this will be something like:
>>> ls -lda /tmp/.ooR*
>>> -rw-rw-rw- 1 jenkins  jenkins  0 Dec 24 23:19 
>>> /tmp/.ooRexx-5.0.0-64-1002.lock
>>> srwxrwxrwx 1 jenkins  jenkins  0 Dec 24 23:49 
>>> /tmp/.ooRexx-5.0.0-64-1002.service
>>> -rw-rw-rw- 1 www-data www-data 0 Dec 24 23:52 /tmp/.ooRexx-5.0.0-64-33.lock
>>> srwxrwxrwx 1 www-data www-data 0 Dec 24 23:49 
>>> /tmp/.ooRexx-5.0.0-64-33.service
>>> I'm a bit concerned about the file permissions global RW bits, but to my 
>>> surprise rm nevertheless refuses to remove both the lock and the service 
>>> "file" (rm: cannot remove '/tmp/.ooRexx-5.0.0-64-1002.lock': Operation not 
>>> permitted .. I don't understand why)
>>> 
>>> There is one situation that will make rxapi fail to start: if a malicious 
>>> user creates a simple file with the same name as the lock/service file of a 
>>> user.  It might still be a good idea to check whether rxapi can create 
>>> those files (XDG or /tmp) and if not, somehow (but how?) give an error 
>>> indication "cannot create path/.ooRexx...service"
>>> 
>>> On Mon, Dec 24, 2018 at 2:19 PM Rick McGuire >> > wrote:
>>> Ok, from what Bob Martin posted, it sounds like the www-data login does not 
>>> have XDG variables set and also does not have write access to the home 
>>> directory. As others have said, using the home directory is probably a bad 
>>> idea because it could be network-mounted and using it would lock out users 
>>> on other machines. Here is a totally uncompiled and untested patch that 
>>> uses either the XDG_RUNTIME_DIR or /tmp for creating the files and also 
>>> includes the login name in the file names. 
>>> 
>>> Rick
>>> ___
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net 
>>> 
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
>>> 
>> 
>> ___
>> 

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

You probably ran ooRexx back on December 8th, which is when they were
created. You can delete them, but the files will get recreated the next
time you run ooRexx.

Rick

On Tue, Dec 25, 2018 at 6:25 AM P.O. Jonsson  wrote:

> I have no recollection of having made a build on that userID for quite
> some time, hence the question,, it is Erich that uses the „Jenkins“ account
> on the same machine to make the automated builds, hence the question.
>
> Here are the further details of these files
>
> -rw-rw-rw-   1 postaff  0 Dec  8 16:19 .ooRexx-5.0.0-64.lock
> srwxrwxrwx   1 postaff  0 Dec  8 16:19 .ooRexx-5.0.0-64.service
>
> I assume I can safely delete them?
>
> Von meinen Macbook gesendet
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
> Am 25.12.2018 um 11:42 schrieb Rick McGuire :
>
> If the build was running under your userid, that file got created when
> rxapi was launched during the build process. That's the file that is used
> to ensure that only one copy of rxapi runs per user.
>
> Rick
>
> On Tue, Dec 25, 2018 at 5:09 AM P.O. Jonsson  wrote:
>
>> Dear Erich,
>>
>> I was going into my user account on the Mac Mini Jenkins slave today and
>> noticed a hidden file "*.ooRexx-5.0.0-64.lock*“ in my home directory
>> (Users/po) Is this something that is coming out of the Jenkins build? How
>> can the lock file be in my account? I have no ooRexx installation in that
>> account and the machine wide installation has been removed. some time ago.
>>
>> Can you please explain the latest development with the locking and how it
>> is intended to work? No criticism, just trying to understand.
>>
>> Von meinen Macbook gesendet
>>
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se
>>
>>
>> Am 25.12.2018 um 00:39 schrieb Erich Steinböck <
>> erich.steinbo...@gmail.com>:
>>
>> With a few typos fixed, this seems to work as expected, also in the
>> discussed sudo scenario.
>>
>> also includes the login name in the file names
>>>
>> getuid() returns the id, not the name, so I had changed the %s to %d in
>> the snprintf's
>> I assume getting the name will require getpwuid() - if we want the name
>> instead
>>
>> If no XDG_RUNTIME_DIR is set, this will be something like:
>> ls -lda /tmp/.ooR*
>> -rw-rw-rw- 1 jenkins  jenkins  0 Dec 24 23:19
>> /tmp/.ooRexx-5.0.0-64-1002.lock
>> srwxrwxrwx 1 jenkins  jenkins  0 Dec 24 23:49
>> /tmp/.ooRexx-5.0.0-64-1002.service
>> -rw-rw-rw- 1 www-data www-data 0 Dec 24 23:52
>> /tmp/.ooRexx-5.0.0-64-33.lock
>> srwxrwxrwx 1 www-data www-data 0 Dec 24 23:49
>> /tmp/.ooRexx-5.0.0-64-33.service
>> I'm a bit concerned about the file permissions global RW bits, but to my
>> surprise rm nevertheless refuses to remove both the lock and the service
>> "file" (rm: cannot remove '/tmp/.ooRexx-5.0.0-64-1002.lock': Operation not
>> permitted .. I don't understand why)
>>
>> There is one situation that will make rxapi fail to start: if a malicious
>> user creates a simple file with the same name as the lock/service file of a
>> user.  It might still be a good idea to check whether rxapi can create
>> those files (XDG or /tmp) and if not, somehow (but how?) give an error
>> indication "cannot create path/.ooRexx...service"
>>
>> On Mon, Dec 24, 2018 at 2:19 PM Rick McGuire 
>> wrote:
>>
>>> Ok, from what Bob Martin posted, it sounds like the www-data login does
>>> not have XDG variables set and also does not have write access to the home
>>> directory. As others have said, using the home directory is probably a bad
>>> idea because it could be network-mounted and using it would lock out users
>>> on other machines. Here is a totally uncompiled and untested patch that
>>> uses either the XDG_RUNTIME_DIR or /tmp for creating the files and also
>>> includes the login name in the file names.
>>>
>>> Rick
>>>
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>>
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[P.O. Jonsson]

I have no recollection of having made a build on that userID for quite some 
time, hence the question,, it is Erich that uses the „Jenkins“ account on the 
same machine to make the automated builds, hence the question.

Here are the further details of these files

-rw-rw-rw-   1 postaff  0 Dec  8 16:19 .ooRexx-5.0.0-64.lock
srwxrwxrwx   1 postaff  0 Dec  8 16:19 .ooRexx-5.0.0-64.service

I assume I can safely delete them?

Von meinen Macbook gesendet

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



> Am 25.12.2018 um 11:42 schrieb Rick McGuire :
> 
> If the build was running under your userid, that file got created when rxapi 
> was launched during the build process. That's the file that is used to ensure 
> that only one copy of rxapi runs per user. 
> 
> Rick
> 
> On Tue, Dec 25, 2018 at 5:09 AM P.O. Jonsson  > wrote:
> Dear Erich,
> 
> I was going into my user account on the Mac Mini Jenkins slave today and 
> noticed a hidden file ".ooRexx-5.0.0-64.lock“ in my home directory (Users/po) 
> Is this something that is coming out of the Jenkins build? How can the lock 
> file be in my account? I have no ooRexx installation in that account and the 
> machine wide installation has been removed. some time ago.
> 
> Can you please explain the latest development with the locking and how it is 
> intended to work? No criticism, just trying to understand. 
> 
> Von meinen Macbook gesendet
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
>> Am 25.12.2018 um 00:39 schrieb Erich Steinböck > >:
>> 
>> With a few typos fixed, this seems to work as expected, also in the 
>> discussed sudo scenario.
>> 
>> also includes the login name in the file names
>> getuid() returns the id, not the name, so I had changed the %s to %d in the 
>> snprintf's
>> I assume getting the name will require getpwuid() - if we want the name 
>> instead
>> 
>> If no XDG_RUNTIME_DIR is set, this will be something like:
>> ls -lda /tmp/.ooR*
>> -rw-rw-rw- 1 jenkins  jenkins  0 Dec 24 23:19 /tmp/.ooRexx-5.0.0-64-1002.lock
>> srwxrwxrwx 1 jenkins  jenkins  0 Dec 24 23:49 
>> /tmp/.ooRexx-5.0.0-64-1002.service
>> -rw-rw-rw- 1 www-data www-data 0 Dec 24 23:52 /tmp/.ooRexx-5.0.0-64-33.lock
>> srwxrwxrwx 1 www-data www-data 0 Dec 24 23:49 
>> /tmp/.ooRexx-5.0.0-64-33.service
>> I'm a bit concerned about the file permissions global RW bits, but to my 
>> surprise rm nevertheless refuses to remove both the lock and the service 
>> "file" (rm: cannot remove '/tmp/.ooRexx-5.0.0-64-1002.lock': Operation not 
>> permitted .. I don't understand why)
>> 
>> There is one situation that will make rxapi fail to start: if a malicious 
>> user creates a simple file with the same name as the lock/service file of a 
>> user.  It might still be a good idea to check whether rxapi can create those 
>> files (XDG or /tmp) and if not, somehow (but how?) give an error indication 
>> "cannot create path/.ooRexx...service"
>> 
>> On Mon, Dec 24, 2018 at 2:19 PM Rick McGuire > > wrote:
>> Ok, from what Bob Martin posted, it sounds like the www-data login does not 
>> have XDG variables set and also does not have write access to the home 
>> directory. As others have said, using the home directory is probably a bad 
>> idea because it could be network-mounted and using it would lock out users 
>> on other machines. Here is a totally uncompiled and untested patch that uses 
>> either the XDG_RUNTIME_DIR or /tmp for creating the files and also includes 
>> the login name in the file names. 
>> 
>> Rick
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net 
>> 
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
>> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

If the build was running under your userid, that file got created when
rxapi was launched during the build process. That's the file that is used
to ensure that only one copy of rxapi runs per user.

Rick

On Tue, Dec 25, 2018 at 5:09 AM P.O. Jonsson  wrote:

> Dear Erich,
>
> I was going into my user account on the Mac Mini Jenkins slave today and
> noticed a hidden file "*.ooRexx-5.0.0-64.lock*“ in my home directory
> (Users/po) Is this something that is coming out of the Jenkins build? How
> can the lock file be in my account? I have no ooRexx installation in that
> account and the machine wide installation has been removed. some time ago.
>
> Can you please explain the latest development with the locking and how it
> is intended to work? No criticism, just trying to understand.
>
> Von meinen Macbook gesendet
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
> Am 25.12.2018 um 00:39 schrieb Erich Steinböck  >:
>
> With a few typos fixed, this seems to work as expected, also in the
> discussed sudo scenario.
>
> also includes the login name in the file names
>>
> getuid() returns the id, not the name, so I had changed the %s to %d in
> the snprintf's
> I assume getting the name will require getpwuid() - if we want the name
> instead
>
> If no XDG_RUNTIME_DIR is set, this will be something like:
> ls -lda /tmp/.ooR*
> -rw-rw-rw- 1 jenkins  jenkins  0 Dec 24 23:19
> /tmp/.ooRexx-5.0.0-64-1002.lock
> srwxrwxrwx 1 jenkins  jenkins  0 Dec 24 23:49
> /tmp/.ooRexx-5.0.0-64-1002.service
> -rw-rw-rw- 1 www-data www-data 0 Dec 24 23:52 /tmp/.ooRexx-5.0.0-64-33.lock
> srwxrwxrwx 1 www-data www-data 0 Dec 24 23:49
> /tmp/.ooRexx-5.0.0-64-33.service
> I'm a bit concerned about the file permissions global RW bits, but to my
> surprise rm nevertheless refuses to remove both the lock and the service
> "file" (rm: cannot remove '/tmp/.ooRexx-5.0.0-64-1002.lock': Operation not
> permitted .. I don't understand why)
>
> There is one situation that will make rxapi fail to start: if a malicious
> user creates a simple file with the same name as the lock/service file of a
> user.  It might still be a good idea to check whether rxapi can create
> those files (XDG or /tmp) and if not, somehow (but how?) give an error
> indication "cannot create path/.ooRexx...service"
>
> On Mon, Dec 24, 2018 at 2:19 PM Rick McGuire 
> wrote:
>
>> Ok, from what Bob Martin posted, it sounds like the www-data login does
>> not have XDG variables set and also does not have write access to the home
>> directory. As others have said, using the home directory is probably a bad
>> idea because it could be network-mounted and using it would lock out users
>> on other machines. Here is a totally uncompiled and untested patch that
>> uses either the XDG_RUNTIME_DIR or /tmp for creating the files and also
>> includes the login name in the file names.
>>
>> Rick
>>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[P.O. Jonsson]

Dear Erich,

I was going into my user account on the Mac Mini Jenkins slave today and 
noticed a hidden file ".ooRexx-5.0.0-64.lock“ in my home directory (Users/po) 
Is this something that is coming out of the Jenkins build? How can the lock 
file be in my account? I have no ooRexx installation in that account and the 
machine wide installation has been removed. some time ago.

Can you please explain the latest development with the locking and how it is 
intended to work? No criticism, just trying to understand. 

Von meinen Macbook gesendet

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se


> Am 25.12.2018 um 00:39 schrieb Erich Steinböck :
> 
> With a few typos fixed, this seems to work as expected, also in the discussed 
> sudo scenario.
> 
> also includes the login name in the file names
> getuid() returns the id, not the name, so I had changed the %s to %d in the 
> snprintf's
> I assume getting the name will require getpwuid() - if we want the name 
> instead
> 
> If no XDG_RUNTIME_DIR is set, this will be something like:
> ls -lda /tmp/.ooR*
> -rw-rw-rw- 1 jenkins  jenkins  0 Dec 24 23:19 /tmp/.ooRexx-5.0.0-64-1002.lock
> srwxrwxrwx 1 jenkins  jenkins  0 Dec 24 23:49 
> /tmp/.ooRexx-5.0.0-64-1002.service
> -rw-rw-rw- 1 www-data www-data 0 Dec 24 23:52 /tmp/.ooRexx-5.0.0-64-33.lock
> srwxrwxrwx 1 www-data www-data 0 Dec 24 23:49 /tmp/.ooRexx-5.0.0-64-33.service
> I'm a bit concerned about the file permissions global RW bits, but to my 
> surprise rm nevertheless refuses to remove both the lock and the service 
> "file" (rm: cannot remove '/tmp/.ooRexx-5.0.0-64-1002.lock': Operation not 
> permitted .. I don't understand why)
> 
> There is one situation that will make rxapi fail to start: if a malicious 
> user creates a simple file with the same name as the lock/service file of a 
> user.  It might still be a good idea to check whether rxapi can create those 
> files (XDG or /tmp) and if not, somehow (but how?) give an error indication 
> "cannot create path/.ooRexx...service"
> 
> On Mon, Dec 24, 2018 at 2:19 PM Rick McGuire  > wrote:
> Ok, from what Bob Martin posted, it sounds like the www-data login does not 
> have XDG variables set and also does not have write access to the home 
> directory. As others have said, using the home directory is probably a bad 
> idea because it could be network-mounted and using it would lock out users on 
> other machines. Here is a totally uncompiled and untested patch that uses 
> either the XDG_RUNTIME_DIR or /tmp for creating the files and also includes 
> the login name in the file names. 
> 
> Rick
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

Using getpwuid() would be better. Based on the code that was there before,
I was assuming getuid() actually returned the username...guess I should
have looked it up first.

Rick

On Mon, Dec 24, 2018 at 6:40 PM Erich Steinböck 
wrote:

> With a few typos fixed, this seems to work as expected, also in the
> discussed sudo scenario.
>
> also includes the login name in the file names
>>
> getuid() returns the id, not the name, so I had changed the %s to %d in
> the snprintf's
> I assume getting the name will require getpwuid() - if we want the name
> instead
>
> If no XDG_RUNTIME_DIR is set, this will be something like:
> ls -lda /tmp/.ooR*
> -rw-rw-rw- 1 jenkins  jenkins  0 Dec 24 23:19
> /tmp/.ooRexx-5.0.0-64-1002.lock
> srwxrwxrwx 1 jenkins  jenkins  0 Dec 24 23:49
> /tmp/.ooRexx-5.0.0-64-1002.service
> -rw-rw-rw- 1 www-data www-data 0 Dec 24 23:52 /tmp/.ooRexx-5.0.0-64-33.lock
> srwxrwxrwx 1 www-data www-data 0 Dec 24 23:49
> /tmp/.ooRexx-5.0.0-64-33.service
> I'm a bit concerned about the file permissions global RW bits, but to my
> surprise rm nevertheless refuses to remove both the lock and the service
> "file" (rm: cannot remove '/tmp/.ooRexx-5.0.0-64-1002.lock': Operation not
> permitted .. I don't understand why)
>
> There is one situation that will make rxapi fail to start: if a malicious
> user creates a simple file with the same name as the lock/service file of a
> user.  It might still be a good idea to check whether rxapi can create
> those files (XDG or /tmp) and if not, somehow (but how?) give an error
> indication "cannot create path/.ooRexx...service"
>
> On Mon, Dec 24, 2018 at 2:19 PM Rick McGuire 
> wrote:
>
>> Ok, from what Bob Martin posted, it sounds like the www-data login does
>> not have XDG variables set and also does not have write access to the home
>> directory. As others have said, using the home directory is probably a bad
>> idea because it could be network-mounted and using it would lock out users
>> on other machines. Here is a totally uncompiled and untested patch that
>> uses either the XDG_RUNTIME_DIR or /tmp for creating the files and also
>> includes the login name in the file names.
>>
>> Rick
>>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Erich Steinböck]

With a few typos fixed, this seems to work as expected, also in the
discussed sudo scenario.

also includes the login name in the file names
>
getuid() returns the id, not the name, so I had changed the %s to %d in the
snprintf's
I assume getting the name will require getpwuid() - if we want the name
instead

If no XDG_RUNTIME_DIR is set, this will be something like:
ls -lda /tmp/.ooR*
-rw-rw-rw- 1 jenkins  jenkins  0 Dec 24 23:19
/tmp/.ooRexx-5.0.0-64-1002.lock
srwxrwxrwx 1 jenkins  jenkins  0 Dec 24 23:49
/tmp/.ooRexx-5.0.0-64-1002.service
-rw-rw-rw- 1 www-data www-data 0 Dec 24 23:52 /tmp/.ooRexx-5.0.0-64-33.lock
srwxrwxrwx 1 www-data www-data 0 Dec 24 23:49
/tmp/.ooRexx-5.0.0-64-33.service
I'm a bit concerned about the file permissions global RW bits, but to my
surprise rm nevertheless refuses to remove both the lock and the service
"file" (rm: cannot remove '/tmp/.ooRexx-5.0.0-64-1002.lock': Operation not
permitted .. I don't understand why)

There is one situation that will make rxapi fail to start: if a malicious
user creates a simple file with the same name as the lock/service file of a
user.  It might still be a good idea to check whether rxapi can create
those files (XDG or /tmp) and if not, somehow (but how?) give an error
indication "cannot create path/.ooRexx...service"

On Mon, Dec 24, 2018 at 2:19 PM Rick McGuire  wrote:

> Ok, from what Bob Martin posted, it sounds like the www-data login does
> not have XDG variables set and also does not have write access to the home
> directory. As others have said, using the home directory is probably a bad
> idea because it could be network-mounted and using it would lock out users
> on other machines. Here is a totally uncompiled and untested patch that
> uses either the XDG_RUNTIME_DIR or /tmp for creating the files and also
> includes the login name in the file names.
>
> Rick
>


www-data-b.patch
Description: Binary data
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

Ok, from what Bob Martin posted, it sounds like the www-data login does not
have XDG variables set and also does not have write access to the home
directory. As others have said, using the home directory is probably a bad
idea because it could be network-mounted and using it would lock out users
on other machines. Here is a totally uncompiled and untested patch that
uses either the XDG_RUNTIME_DIR or /tmp for creating the files and also
includes the login name in the file names.

Rick

On Sat, Dec 22, 2018 at 9:07 AM Erich Steinböck 
wrote:

> No, not yet.  Should we wait for Moritz' feedback, as he was the the one
> who suggested using XDG_RUNTIME_DIR?
>
> On Sat, Dec 22, 2018 at 2:56 PM Rick McGuire 
> wrote:
>
>> Sounds like a reasonable solution...have you tried it yet?
>>
>> Rick
>>
>> On Sat, Dec 22, 2018 at 8:53 AM Erich Steinböck <
>> erich.steinbo...@gmail.com> wrote:
>>
>>> With the new rxapi using $XDG_RUNTIME_DIR for its socket, we are running
>>> into an issue if a Unix user switches users with the "su other-user"
>>> command.
>>> The existing environment is mainly kept intact, and $XDG_RUNTIME_DIR now
>>> points to a location that other-user has no access to.
>>> At this point any rexx script will show the typical start delay due to
>>> rxapi failing to start, and external queues return REX121 Storage for data
>>> queues is exhausted.
>>>
>>> In a scenario where a user switched to root (untested) with su root,
>>> things might become even worse (a socket created by root now blocking the
>>> original user from creating his rxapi socket).
>>>
>>> I suggest dropping rxapi's use of $XDG_RUNTIME_DIR and instead make it
>>> always use the user's home directory.  When using su, the HOME environment
>>> variable will change to the other-user's home directory.
>>> ___
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>


www-data.patch
Description: Binary data
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Michael Lueck]

Greetings ooRexx'ers,

Moritz Hoffmann wrote:

I would not advocate storing the socket in the home directory. At
work, my home directory is on NFS and that would break ooRexx on all
but one machine. From my experience this is a common setup.



I agree with Moritz's statement that it seems common practice in the *ix world 
to NFS mount the home partition to a NFS server.

I happen to have standardized on Samba in place of NFS... and I retain a local 
home directory, have backup scripts to store to the server application user 
profiles, such as Firefox and SeaMonkey.

+1 vote for landing on a scheme which works in as many scenarios as possible.

I am thankful,

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Moritz Hoffmann]

That's interesting! I'm able to reproduce the described behavior on
Debian stretch. The su command is only supposed to be used for
changing the user ID but will preserve the environment as is. The sudo
command will update the environment and clears the XDG_* variables
because it's not a login session, and because it's a safety problem
not to clear them. Here is what I observed:

my user: XDG_RUNTIME_DIR: /run/user/MY_ID
su other_user: XDG_RUNTIME_DIR: /run/user/MY_ID
su root: XDG_RUNTIME_DIR: /run/user/MY_ID
su -: XDG_RUNTIME_DIR unset
sudo -s: XDG_RUNTIME_DIR unset
sudo su: XDG_RUNTIME_DIR unset

I would suggest the following: if XDG_RUNTIME_DIR is unset, use
/tmp/.oorexx-$UID. If XDG_RUNTIME_DIR is set, but
stat(XDG_RUNTIME_DIR).uid != MY_ID, also use /tmp... Otherwise, use
XDG_RUNTIME_DIR.

I would not advocate storing the socket in the home directory. At
work, my home directory is on NFS and that would break ooRexx on all
but one machine. From my experience this is a common setup.

Moritz

On Sat, Dec 22, 2018 at 2:53 PM Erich Steinböck
 wrote:
>
> With the new rxapi using $XDG_RUNTIME_DIR for its socket, we are running into 
> an issue if a Unix user switches users with the "su other-user" command.
> The existing environment is mainly kept intact, and $XDG_RUNTIME_DIR now 
> points to a location that other-user has no access to.
> At this point any rexx script will show the typical start delay due to rxapi 
> failing to start, and external queues return REX121 Storage for data queues 
> is exhausted.
>
> In a scenario where a user switched to root (untested) with su root, things 
> might become even worse (a socket created by root now blocking the original 
> user from creating his rxapi socket).
>
> I suggest dropping rxapi's use of $XDG_RUNTIME_DIR and instead make it always 
> use the user's home directory.  When using su, the HOME environment variable 
> will change to the other-user's home directory.
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel



-- 
Moritz Hoffmann;
http://antiguru.de/


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Enrico Sorichetti via Oorexx-devel]

Any linux/BSD/Apple user knows that sudo and su are prone to create 
unpredictable results 
I would not waste time researching a solution for a murky situation 
I would mark it as a permanent restriction / producing unpredictable results 

I just created a test user and  found that 
The $HOME var points to the SU’ ed user home directory
But after the switch the working directory does not change 
Some environment variables are carried over ,some other not ,
As I said a murky situation overall, 
The  will never be clean 

On apple there is no need to SU, the SUPERUSER does not exists 
All is done thru the administrator attribute of any user
And SUDO to activate the super powers

In my experience for Linux and FeeBSD instances sudo is more than enough
On freebsd when doing the after install customisation 
it was faster to login as root and run the post install from there
The pkg command is quite picky

cheers
E





> On 22 Dec 2018, at 15:12, Rick McGuire  wrote:
> 
> It would be useful to have the feedback to see if always using the user's 
> home directory works or now. I'm concerned we might run into similar access 
> issues with the switch. If so, then we might need to use something in /tmp 
> and include the username in the files we create, which is less secure, but 
> will continue to work with a switch. 
> 
> Rick
> 
> On Sat, Dec 22, 2018 at 9:07 AM Erich Steinböck  > wrote:
> No, not yet.  Should we wait for Moritz' feedback, as he was the the one who 
> suggested using XDG_RUNTIME_DIR?
> 
> On Sat, Dec 22, 2018 at 2:56 PM Rick McGuire  > wrote:
> Sounds like a reasonable solution...have you tried it yet? 
> 
> Rick
> 
> On Sat, Dec 22, 2018 at 8:53 AM Erich Steinböck  > wrote:
> With the new rxapi using $XDG_RUNTIME_DIR for its socket, we are running into 
> an issue if a Unix user switches users with the "su other-user" command.
> The existing environment is mainly kept intact, and $XDG_RUNTIME_DIR now 
> points to a location that other-user has no access to.
> At this point any rexx script will show the typical start delay due to rxapi 
> failing to start, and external queues return REX121 Storage for data queues 
> is exhausted.
> 
> In a scenario where a user switched to root (untested) with su root, things 
> might become even worse (a socket created by root now blocking the original 
> user from creating his rxapi socket).
> 
> I suggest dropping rxapi's use of $XDG_RUNTIME_DIR and instead make it always 
> use the user's home directory.  When using su, the HOME environment variable 
> will change to the other-user's home directory.
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[P.O. Jonsson]

I am not sure what will happen for MAC (being *NIX) users;l with the current 
default placement of ooRexx into ~Applications/ooRexx5.0.0 (in my case 
/Users/po/Applications/ooRexx5.0.0) the ooRexx installation is per user and 
not, as in version 4 or as in the BSF4ooRexx generic and available for all 
users. Hence changing to another user you no longer refer to the same Rexx 
interpreter (if both users have ooRexx installed) or the new user have no 
ooRexx at all. Keep in mind to test this.

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




> Am 22.12.2018 um 14:52 schrieb Erich Steinböck :
> 
> With the new rxapi using $XDG_RUNTIME_DIR for its socket, we are running into 
> an issue if a Unix user switches users with the "su other-user" command.
> The existing environment is mainly kept intact, and $XDG_RUNTIME_DIR now 
> points to a location that other-user has no access to.
> At this point any rexx script will show the typical start delay due to rxapi 
> failing to start, and external queues return REX121 Storage for data queues 
> is exhausted.
> 
> In a scenario where a user switched to root (untested) with su root, things 
> might become even worse (a socket created by root now blocking the original 
> user from creating his rxapi socket).
> 
> I suggest dropping rxapi's use of $XDG_RUNTIME_DIR and instead make it always 
> use the user's home directory.  When using su, the HOME environment variable 
> will change to the other-user's home directory.
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Erich Steinböck]

No, not yet.  Should we wait for Moritz' feedback, as he was the the one
who suggested using XDG_RUNTIME_DIR?

On Sat, Dec 22, 2018 at 2:56 PM Rick McGuire  wrote:

> Sounds like a reasonable solution...have you tried it yet?
>
> Rick
>
> On Sat, Dec 22, 2018 at 8:53 AM Erich Steinböck <
> erich.steinbo...@gmail.com> wrote:
>
>> With the new rxapi using $XDG_RUNTIME_DIR for its socket, we are running
>> into an issue if a Unix user switches users with the "su other-user"
>> command.
>> The existing environment is mainly kept intact, and $XDG_RUNTIME_DIR now
>> points to a location that other-user has no access to.
>> At this point any rexx script will show the typical start delay due to
>> rxapi failing to start, and external queues return REX121 Storage for data
>> queues is exhausted.
>>
>> In a scenario where a user switched to root (untested) with su root,
>> things might become even worse (a socket created by root now blocking the
>> original user from creating his rxapi socket).
>>
>> I suggest dropping rxapi's use of $XDG_RUNTIME_DIR and instead make it
>> always use the user's home directory.  When using su, the HOME environment
>> variable will change to the other-user's home directory.
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

Sounds like a reasonable solution...have you tried it yet?

Rick

On Sat, Dec 22, 2018 at 8:53 AM Erich Steinböck 
wrote:

> With the new rxapi using $XDG_RUNTIME_DIR for its socket, we are running
> into an issue if a Unix user switches users with the "su other-user"
> command.
> The existing environment is mainly kept intact, and $XDG_RUNTIME_DIR now
> points to a location that other-user has no access to.
> At this point any rexx script will show the typical start delay due to
> rxapi failing to start, and external queues return REX121 Storage for data
> queues is exhausted.
>
> In a scenario where a user switched to root (untested) with su root,
> things might become even worse (a socket created by root now blocking the
> original user from creating his rxapi socket).
>
> I suggest dropping rxapi's use of $XDG_RUNTIME_DIR and instead make it
> always use the user's home directory.  When using su, the HOME environment
> variable will change to the other-user's home directory.
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Erich Steinböck]

With the new rxapi using $XDG_RUNTIME_DIR for its socket, we are running
into an issue if a Unix user switches users with the "su other-user"
command.
The existing environment is mainly kept intact, and $XDG_RUNTIME_DIR now
points to a location that other-user has no access to.
At this point any rexx script will show the typical start delay due to
rxapi failing to start, and external queues return REX121 Storage for data
queues is exhausted.

In a scenario where a user switched to root (untested) with su root, things
might become even worse (a socket created by root now blocking the original
user from creating his rxapi socket).

I suggest dropping rxapi's use of $XDG_RUNTIME_DIR and instead make it
always use the user's home directory.  When using su, the HOME environment
variable will change to the other-user's home directory.
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rony G. Flatscher]

Fresh build, trying to compile until:

[ 76%] Building CXX object 
CMakeFiles/rxapi.dir/rexxapi/server/platform/unix/linux/APIService.cpp.o

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:
 In function ´int acquireLock(const char*)`:

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:87:16:
 error: ´lockfd` was not declared in this scope
 if (flock (lockfd, LOCK_EX | LOCK_NB) < 0)
^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:
 In function ´void releaseLock(const char*, int)`:

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:108:24:
 error: ´unline` was not declared in this scope
 unline(lockFileName);
^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:
 In function ´int main(int, char**)`:

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:123:23:
 error: ´MAX_PATH` was not declared in this scope
 char lockFileName[MAX_PATH];
   ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:137:14:
 error: ´lockFileName` was not declared in this scope
 snprintf(lockFileName, sizeof(lockFileName), 
"%s/.ooRexx-%d.%d.%d-%s.lock", homePath, ORX_VER, ORX_REL, ORX_MOD,
  ^
CMakeFiles/rxapi.dir/build.make:422: recipe for target 
'CMakeFiles/rxapi.dir/rexxapi/server/platform/unix/linux/APIService.cpp.o' 
failed
make[2]: *** 
[CMakeFiles/rxapi.dir/rexxapi/server/platform/unix/linux/APIService.cpp.o] 
Error 1
CMakeFiles/Makefile2:105: recipe for target 'CMakeFiles/rxapi.dir/all' 
failed
make[1]: *** [CMakeFiles/rxapi.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2
rony@rony-linux:~/work/oorexx/rick_rxapi_sandbox$ 
 

---rony

On 01.12.2018 17:24, Rick McGuire wrote:
> I found a fairly simple example of using a lock file that was simpler than 
> using a pid file, so
> went with that.
>
> Rick
>
> On Sat, Dec 1, 2018 at 10:48 AM Erich Steinböck  > wrote:
>
> This question seems to exactly cover our situation:
> 
> https://stackoverflow.com/questions/30742508/linux-local-communication-sockets-why-is-bind-not-failing-as-expected
>
> The solution seems to better than what I proposed
>
> On Sat, Dec 1, 2018 at 4:13 PM Erich Steinböck  > wrote:
>
> try this again after commenting out the call to the method that 
> performs the unlink().
>
> If I comment out the call to checkServiceName, the bind fails (and 
> with it rxapi) even the
> "first" time, unless I manually remove the 
> $XDG_RUNTIME_DIR/.ooRexx-5.0.0-64.service
> special file
>
> kill the first instance and try launching rxapi again to see if 
> successfully binds.
>
> If rxapi is started successfully, and I kill it, the special file 
> still exists, and as
> such starting any further instances of rxapi fail, until I manually 
> remove the special
> file again.
>
> We probably need rxapi to open a second, standard file (in the same 
> XDG_RUNTIME_DIR
> location) that it opens, and any further rxapi instances would only 
> proceed if they could
> successfully unlink this file, which would be the case if the initial 
> rxapi instance has
> ended or was killed.  (Well, yes, that's probably exactly what you 
> describe as "still a
> need for a .pid file")
>
> On Sat, Dec 1, 2018 at 3:21 PM Rick McGuire  > wrote:
>
> Erich, 
>
> One more experiment. Since there is some automatic cleanup 
> involved with that file
> because of its location, could you try this again after 
> commenting out the call to the
> method that performs the unlink(). From what I've read, the 
> second bind should fail,
> which will cause the second instance to close. 
>
> However, there's another scenario I'm worried about. If the first 
> experiment works,
> kill the first instance and try launching rxapi again to see if 
> successfully binds.
>
> Rick
>
> On Sat, Dec 1, 2018 at 8:54 AM Erich Steinböck 
>  > wrote:
>
> One thing that needs to be checked out is what happens if 
> a second version of
> rxapi gets launched.
> .. there's also some code to unlink() the file before the 
> bind operation that
> I'm hoping will fail if the socket is still in use.  
>
>
> 

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

I found a fairly simple example of using a lock file that was simpler than
using a pid file, so went with that.

Rick

On Sat, Dec 1, 2018 at 10:48 AM Erich Steinböck 
wrote:

> This question seems to exactly cover our situation:
>
> https://stackoverflow.com/questions/30742508/linux-local-communication-sockets-why-is-bind-not-failing-as-expected
>
> The solution seems to better than what I proposed
>
> On Sat, Dec 1, 2018 at 4:13 PM Erich Steinböck 
> wrote:
>
>> try this again after commenting out the call to the method that performs
>>> the unlink().
>>>
>> If I comment out the call to checkServiceName, the bind fails (and with
>> it rxapi) even the "first" time, unless I manually remove the
>> $XDG_RUNTIME_DIR/.ooRexx-5.0.0-64.service special file
>>
>> kill the first instance and try launching rxapi again to see if
>>> successfully binds.
>>>
>> If rxapi is started successfully, and I kill it, the special file still
>> exists, and as such starting any further instances of rxapi fail, until I
>> manually remove the special file again.
>>
>> We probably need rxapi to open a second, standard file (in the same
>> XDG_RUNTIME_DIR location) that it opens, and any further rxapi instances
>> would only proceed if they could successfully unlink this file, which would
>> be the case if the initial rxapi instance has ended or was killed.  (Well,
>> yes, that's probably exactly what you describe as "still a need for a .pid
>> file")
>>
>> On Sat, Dec 1, 2018 at 3:21 PM Rick McGuire 
>> wrote:
>>
>>> Erich,
>>>
>>> One more experiment. Since there is some automatic cleanup involved with
>>> that file because of its location, could you try this again after
>>> commenting out the call to the method that performs the unlink(). From what
>>> I've read, the second bind should fail, which will cause the second
>>> instance to close.
>>>
>>> However, there's another scenario I'm worried about. If the first
>>> experiment works, kill the first instance and try launching rxapi again to
>>> see if successfully binds.
>>>
>>> Rick
>>>
>>> On Sat, Dec 1, 2018 at 8:54 AM Erich Steinböck <
>>> erich.steinbo...@gmail.com> wrote:
>>>
 One thing that needs to be checked out is what happens if a second
> version of rxapi gets launched.
> .. there's also some code to unlink() the file before the bind
> operation that I'm hoping will fail if the socket is still in use.


 On Linux, rxapi can be started a second time, with both of them
 continuing to listenForConnections()
 The reason is, as you suspected, with unlink, which returns 0 although
 the first rxapi still has this socket open.  The docs seem to confirm
 this.  https://linux.die.net/man/2/unlink "If the name referred to a
 socket, fifo or device the name for it is removed but processes which have
 the object open may continue to use it."

>>> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Erich Steinböck]

This question seems to exactly cover our situation:
https://stackoverflow.com/questions/30742508/linux-local-communication-sockets-why-is-bind-not-failing-as-expected

The solution seems to better than what I proposed

On Sat, Dec 1, 2018 at 4:13 PM Erich Steinböck 
wrote:

> try this again after commenting out the call to the method that performs
>> the unlink().
>>
> If I comment out the call to checkServiceName, the bind fails (and with it
> rxapi) even the "first" time, unless I manually remove the
> $XDG_RUNTIME_DIR/.ooRexx-5.0.0-64.service special file
>
> kill the first instance and try launching rxapi again to see if
>> successfully binds.
>>
> If rxapi is started successfully, and I kill it, the special file still
> exists, and as such starting any further instances of rxapi fail, until I
> manually remove the special file again.
>
> We probably need rxapi to open a second, standard file (in the same
> XDG_RUNTIME_DIR location) that it opens, and any further rxapi instances
> would only proceed if they could successfully unlink this file, which would
> be the case if the initial rxapi instance has ended or was killed.  (Well,
> yes, that's probably exactly what you describe as "still a need for a .pid
> file")
>
> On Sat, Dec 1, 2018 at 3:21 PM Rick McGuire  wrote:
>
>> Erich,
>>
>> One more experiment. Since there is some automatic cleanup involved with
>> that file because of its location, could you try this again after
>> commenting out the call to the method that performs the unlink(). From what
>> I've read, the second bind should fail, which will cause the second
>> instance to close.
>>
>> However, there's another scenario I'm worried about. If the first
>> experiment works, kill the first instance and try launching rxapi again to
>> see if successfully binds.
>>
>> Rick
>>
>> On Sat, Dec 1, 2018 at 8:54 AM Erich Steinböck <
>> erich.steinbo...@gmail.com> wrote:
>>
>>> One thing that needs to be checked out is what happens if a second
 version of rxapi gets launched.
 .. there's also some code to unlink() the file before the bind
 operation that I'm hoping will fail if the socket is still in use.
>>>
>>>
>>> On Linux, rxapi can be started a second time, with both of them
>>> continuing to listenForConnections()
>>> The reason is, as you suspected, with unlink, which returns 0 although
>>> the first rxapi still has this socket open.  The docs seem to confirm
>>> this.  https://linux.die.net/man/2/unlink "If the name referred to a
>>> socket, fifo or device the name for it is removed but processes which have
>>> the object open may continue to use it."
>>>
>>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Erich Steinböck]

>
> try this again after commenting out the call to the method that performs
> the unlink().
>
If I comment out the call to checkServiceName, the bind fails (and with it
rxapi) even the "first" time, unless I manually remove the
$XDG_RUNTIME_DIR/.ooRexx-5.0.0-64.service special file

kill the first instance and try launching rxapi again to see if
> successfully binds.
>
If rxapi is started successfully, and I kill it, the special file still
exists, and as such starting any further instances of rxapi fail, until I
manually remove the special file again.

We probably need rxapi to open a second, standard file (in the same
XDG_RUNTIME_DIR location) that it opens, and any further rxapi instances
would only proceed if they could successfully unlink this file, which would
be the case if the initial rxapi instance has ended or was killed.  (Well,
yes, that's probably exactly what you describe as "still a need for a .pid
file")

On Sat, Dec 1, 2018 at 3:21 PM Rick McGuire  wrote:

> Erich,
>
> One more experiment. Since there is some automatic cleanup involved with
> that file because of its location, could you try this again after
> commenting out the call to the method that performs the unlink(). From what
> I've read, the second bind should fail, which will cause the second
> instance to close.
>
> However, there's another scenario I'm worried about. If the first
> experiment works, kill the first instance and try launching rxapi again to
> see if successfully binds.
>
> Rick
>
> On Sat, Dec 1, 2018 at 8:54 AM Erich Steinböck 
> wrote:
>
>> One thing that needs to be checked out is what happens if a second
>>> version of rxapi gets launched.
>>> .. there's also some code to unlink() the file before the bind operation
>>> that I'm hoping will fail if the socket is still in use.
>>
>>
>> On Linux, rxapi can be started a second time, with both of them
>> continuing to listenForConnections()
>> The reason is, as you suspected, with unlink, which returns 0 although
>> the first rxapi still has this socket open.  The docs seem to confirm
>> this.  https://linux.die.net/man/2/unlink "If the name referred to a
>> socket, fifo or device the name for it is removed but processes which have
>> the object open may continue to use it."
>>
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

Erich,

One more experiment. Since there is some automatic cleanup involved with
that file because of its location, could you try this again after
commenting out the call to the method that performs the unlink(). From what
I've read, the second bind should fail, which will cause the second
instance to close.

However, there's another scenario I'm worried about. If the first
experiment works, kill the first instance and try launching rxapi again to
see if successfully binds.

Rick

On Sat, Dec 1, 2018 at 8:54 AM Erich Steinböck 
wrote:

> One thing that needs to be checked out is what happens if a second version
>> of rxapi gets launched.
>> .. there's also some code to unlink() the file before the bind operation
>> that I'm hoping will fail if the socket is still in use.
>
>
> On Linux, rxapi can be started a second time, with both of them continuing
> to listenForConnections()
> The reason is, as you suspected, with unlink, which returns 0 although the
> first rxapi still has this socket open.  The docs seem to confirm this.
> https://linux.die.net/man/2/unlink "If the name referred to a socket,
> fifo or device the name for it is removed but processes which have the
> object open may continue to use it."
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

Rats. Looks like there is still a need for a .pid file. Fortunately, we can
store it in the same location, so there are still no privileges required.
The code can pretty much be copied from the old version.

Rick

On Sat, Dec 1, 2018 at 8:54 AM Erich Steinböck 
wrote:

> One thing that needs to be checked out is what happens if a second version
>> of rxapi gets launched.
>> .. there's also some code to unlink() the file before the bind operation
>> that I'm hoping will fail if the socket is still in use.
>
>
> On Linux, rxapi can be started a second time, with both of them continuing
> to listenForConnections()
> The reason is, as you suspected, with unlink, which returns 0 although the
> first rxapi still has this socket open.  The docs seem to confirm this.
> https://linux.die.net/man/2/unlink "If the name referred to a socket,
> fifo or device the name for it is removed but processes which have the
> object open may continue to use it."
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Erich Steinböck]

>
> One thing that needs to be checked out is what happens if a second version
> of rxapi gets launched.
> .. there's also some code to unlink() the file before the bind operation
> that I'm hoping will fail if the socket is still in use.


On Linux, rxapi can be started a second time, with both of them continuing
to listenForConnections()
The reason is, as you suspected, with unlink, which returns 0 although the
first rxapi still has this socket open.  The docs seem to confirm this.
https://linux.die.net/man/2/unlink "If the name referred to a socket, fifo
or device the name for it is removed but processes which have the object
open may continue to use it."
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Enrico Sorichetti via Oorexx-devel]

And here is the backtrace for the same situations 

My script 

[enrico@enrico-imac zz]$lldb -- rexx unxmit file206.xmi
(lldb) target create "rexx"
Current executable set to 'rexx' (x86_64).
(lldb) settings set -- target.run-args  "unxmit" "file206.xmi"
(lldb) r
Process 4908 launched: '/Users/enrico/rxapi/bin/rexx' (x86_64)
unxmit   - Started : 23:45:53

unxmit   - Input   : file206.xmi
unxmit   - $$cbtdoc  recds( 145) bytes(  8231) 
file(file206/$$cbtdoc.txt)
unxmit   - $$pcdoc   recds( 139) bytes(  7895) file(file206/$$pcdoc.txt)
unxmit   - $updjcl   recds(  16) bytes(   593) file(file206/$updjcl.txt)
unxmit   - dcoljcl   recds( 118) bytes(  3560) file(file206/dcoljcl.txt)
unxmit   - parsrtn   recds(  80) bytes(  3549) file(file206/parsrtn.txt)
unxmit   - rexxrtn   recds(2837) bytes(103188) file(file206/rexxrtn.txt)
unxmit   - Ended   : 23:45:53 Elapsed : 0
*
Process 4908 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION 
(code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x0001003f7c48 
librexxapi.5.0.0.dylib`ApiConnection::~ApiConnection(this=0x000101000120) 
at CSStream.hpp:64
   61   {
   62   public:
   63   inline ApiConnection() : errcode(CSERROR_OK), messageBuffer(NULL) { 
}
-> 64   inline ~ApiConnection() { disconnect(); if (messageBuffer != NULL) 
{ free(messageBuffer); } }
   65   
   66   inline CSErrorCodeT getError()
   67   {
Target 0: (rexx) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION 
(code=EXC_I386_INVOP, subcode=0x0)
  * frame #0: 0x0001003f7c48 
librexxapi.5.0.0.dylib`ApiConnection::~ApiConnection(this=0x000101000120) 
at CSStream.hpp:64
frame #1: 0x0001003f77a2 
librexxapi.5.0.0.dylib`LocalAPIManager::closeConnection(this=0x0001011003b0,
 connection=0x000101000120) at LocalAPIManager.cpp:336
frame #2: 0x0001003f73df 
librexxapi.5.0.0.dylib`LocalAPIManager::shutdownConnections(this=0x0001011003b0)
 at LocalAPIManager.cpp:165
frame #3: 0x0001003f72c2 
librexxapi.5.0.0.dylib`LocalAPIManager::shutdownInstance() at 
LocalAPIManager.cpp:89
frame #4: 0x000100400a59 
librexxapi.5.0.0.dylib`::RexxDeleteSessionQueue() at QueuesAPI.cpp:356
frame #5: 0x0001001d29c7 
librexx.5.0.0.dylib`Interpreter::terminateInterpreter() at Interpreter.cpp:252
frame #6: 0x000100106a3f 
librexx.5.0.0.dylib`::Terminate(c=0x000102011840) at 
InterpreterInstanceStubs.cpp:58
frame #7: 0x00012e06 
rexx`RexxInstance_::Terminate(this=0x000102011840) at oorexxapi.h:753
frame #8: 0x00012b90 rexx`main(argc=3, argv=0x7ffeefbff7f8) at 
rexx.cpp:174
frame #9: 0x7fff71059015 libdyld.dylib`start + 1
frame #10: 0x7fff71059015 libdyld.dylib`start + 1
(lldb) q
Quitting LLDB will kill one or more processes. Do you really want to proceed: 
[Y/n] Y


The test suite 

[enrico@enrico-imac ooRexx.tests.svn]$lldb -- rexx testOORexx.rex -s -X 
native_api
(lldb) target create "rexx"
Current executable set to 'rexx' (x86_64).
(lldb) settings set -- target.run-args  "testOORexx.rex" "-s" "-X" "native_api"
(lldb) r
Process 4913 launched: '/Users/enrico/rxapi/bin/rexx' (x86_64)
Searching for test containers
Executing automated test suite
Executing tests from .../enrico/ooRexx.tests.svn/ooRexx/SimpleTests.testGroup
Executing tests from .../ooRexx/extensions/hostemu/hostemu.testGroup
Executing tests from .../extensions/platform/unix/rxunixsys/SysUnix.testGroup
Executing tests from .../ooRexx/extensions/rxsock/socketClass.testGroup
Executing tests from .../ooRexx/extensions/rxregexp/rxregexp.testGroup
Executing tests from .../ooRexx.tests.svn/ooRexx/extensions/json/json.testGroup
Executing tests from .../ooRexx/extensions/rxmath/RxMath.testGroup
Executing tests from .../ooRexx/utilities/rxqueue/rxQueue.testGroup
Process 4913 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGPIPE
frame #0: 0x7fff711a9de2 libsystem_kernel.dylib`__sendto + 10
libsystem_kernel.dylib`__sendto:
->  0x7fff711a9de2 <+10>: jae0x7fff711a9dec; <+20>
0x7fff711a9de4 <+12>: movq   %rax, %rdi
0x7fff711a9de7 <+15>: jmp0x7fff711a0b0e; cerror
0x7fff711a9dec <+20>: retq   
Target 0: (rexx) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGPIPE
  * frame #0: 0x7fff711a9de2 libsystem_kernel.dylib`__sendto + 10
frame #1: 0x0001004076ca 
librexxapi.5.0.0.dylib`SysSocketConnection::write(this=0x000100502060, 
buf=0x7ffeefbfa910, bufsize=600, byteswritten=0x7ffeefbfa828) at 
SysCSStream.cpp:115
frame #2: 0x000100407786 
librexxapi.5.0.0.dylib`SysSocketConnection::write(this=0x000100502060, 
buf=0x7ffeefbfa910, bufsize=600, buf2=0x, buf2size=0, 
byteswritten=0x7ffeefbfa828) at SysCSStream.cpp:145
frame #3: 

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

Me, no...but perhaps someone else does.

Rick

On Wed, Nov 28, 2018 at 5:23 PM Enrico Sorichetti via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:

> First attempt with a script I wrote
>
>
> [enrico@enrico-imac zz]$lldb -- rexx unxmit FILE206.xmi
> (lldb) target create "rexx"
> Current executable set to 'rexx' (x86_64).
> (lldb) settings set -- target.run-args  "unxmit" "FILE206.xmi"
> (lldb) run
> Process 4488 launched: '/Users/enrico/rxapi/bin/rexx' (x86_64)
> unxmit   - Started : 23:03:45
>
> unxmit   - Input   : FILE206.xmi
> unxmit   - $$cbtdoc  recds( 145) bytes(  8231)
> file(FILE206/$$cbtdoc.txt)
> unxmit   - $$pcdoc   recds( 139) bytes(  7895)
> file(FILE206/$$pcdoc.txt)
> unxmit   - $updjcl   recds(  16) bytes(   593)
> file(FILE206/$updjcl.txt)
> unxmit   - dcoljcl   recds( 118) bytes(  3560)
> file(FILE206/dcoljcl.txt)
> unxmit   - parsrtn   recds(  80) bytes(  3549)
> file(FILE206/parsrtn.txt)
> unxmit   - rexxrtn   recds(2837) bytes(103188)
> file(FILE206/rexxrtn.txt)
> unxmit   - Ended   : 23:03:45 Elapsed : 0
> *
> Process 4488 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
> frame #0: 0x0001003f7c48
> librexxapi.5.0.0.dylib`ApiConnection::~ApiConnection(this=0x000101500190)
> at CSStream.hpp:64
>61  {
>62  public:
>63  inline ApiConnection() : errcode(CSERROR_OK),
> messageBuffer(NULL) { }
> -> 64  inline ~ApiConnection() { disconnect(); if (messageBuffer !=
> NULL) { free(messageBuffer); } }
>65
>66  inline CSErrorCodeT getError()
>67  {
> Target 0: (rexx) stopped.
> (lldb) frame info
> frame #0: 0x0001003f7c48
> librexxapi.5.0.0.dylib`ApiConnection::~ApiConnection(this=0x000101500190)
> at CSStream.hpp:64
> (lldb) frame 0
> invalid command 'frame 0'.
> (lldb) frame select 0
> frame #0: 0x0001003f7c48
> librexxapi.5.0.0.dylib`ApiConnection::~ApiConnection(this=0x000101500190)
> at CSStream.hpp:64
>61  {
>62  public:
>63  inline ApiConnection() : errcode(CSERROR_OK),
> messageBuffer(NULL) { }
> -> 64  inline ~ApiConnection() { disconnect(); if (messageBuffer !=
> NULL) { free(messageBuffer); } }
>65
>66  inline CSErrorCodeT getError()
>67  {
> (lldb) frame variable
> (SysLocalSocketConnection *) this = 0x000101500190
> (lldb) quit
> Quitting LLDB will kill one or more processes. Do you really want to
> proceed: [Y/n] Y
> [enrico@enrico-imac zz]$
>
>
> The interrupt occurs after a say “*"
> When processing the exit instruction,
> Changing the exit to a return did not change anything
>
>
> And now the result with the test suite,
> [enrico@enrico-imac ooRexx.tests.svn]$lldb -- rexx testOORexx.rex -s -X
> native_api
> (lldb) target create "rexx"
> Current executable set to 'rexx' (x86_64).
> (lldb) settings set -- target.run-args  "testOORexx.rex" "-s" "-X"
> "native_api"
> (lldb) r
> Process 4562 launched: '/Users/enrico/rxapi/bin/rexx' (x86_64)
> Searching for test containers
> Executing automated test suite
> Executing tests from
> .../enrico/ooRexx.tests.svn/ooRexx/SimpleTests.testGroup
> Executing tests from .../ooRexx/extensions/hostemu/hostemu.testGroup
> Executing tests from
> .../extensions/platform/unix/rxunixsys/SysUnix.testGroup
> Executing tests from .../ooRexx/extensions/rxsock/socketClass.testGroup
> Executing tests from .../ooRexx/extensions/rxregexp/rxregexp.testGroup
> Executing tests from
> .../ooRexx.tests.svn/ooRexx/extensions/json/json.testGroup
> Executing tests from .../ooRexx/extensions/rxmath/RxMath.testGroup
> Executing tests from .../ooRexx/utilities/rxqueue/rxQueue.testGroup
> Process 4562 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGPIPE
> frame #0: 0x7fff711a9de2 libsystem_kernel.dylib`__sendto + 10
> libsystem_kernel.dylib`__sendto:
> ->  0x7fff711a9de2 <+10>: jae0x7fff711a9dec; <+20>
> 0x7fff711a9de4 <+12>: movq   %rax, %rdi
> 0x7fff711a9de7 <+15>: jmp0x7fff711a0b0e; cerror
> 0x7fff711a9dec <+20>: retq
> Target 0: (rexx) stopped.
> (lldb) frame info
> frame #0: 0x7fff711a9de2 libsystem_kernel.dylib`__sendto + 10
> (lldb) frame select 0
> frame #0: 0x7fff711a9de2 libsystem_kernel.dylib`__sendto + 10
> libsystem_kernel.dylib`__sendto:
> ->  0x7fff711a9de2 <+10>: jae0x7fff711a9dec; <+20>
> 0x7fff711a9de4 <+12>: movq   %rax, %rdi
> 0x7fff711a9de7 <+15>: jmp0x7fff711a0b0e; cerror
> 0x7fff711a9dec <+20>: retq
> (lldb) frame variable
> (lldb) q
>
>
> Do You have enough hints to proceed
>
> E
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Enrico Sorichetti via Oorexx-devel]

First attempt with a script I wrote 


[enrico@enrico-imac zz]$lldb -- rexx unxmit FILE206.xmi
(lldb) target create "rexx"
Current executable set to 'rexx' (x86_64).
(lldb) settings set -- target.run-args  "unxmit" "FILE206.xmi"
(lldb) run
Process 4488 launched: '/Users/enrico/rxapi/bin/rexx' (x86_64)
unxmit   - Started : 23:03:45

unxmit   - Input   : FILE206.xmi
unxmit   - $$cbtdoc  recds( 145) bytes(  8231) 
file(FILE206/$$cbtdoc.txt)
unxmit   - $$pcdoc   recds( 139) bytes(  7895) file(FILE206/$$pcdoc.txt)
unxmit   - $updjcl   recds(  16) bytes(   593) file(FILE206/$updjcl.txt)
unxmit   - dcoljcl   recds( 118) bytes(  3560) file(FILE206/dcoljcl.txt)
unxmit   - parsrtn   recds(  80) bytes(  3549) file(FILE206/parsrtn.txt)
unxmit   - rexxrtn   recds(2837) bytes(103188) file(FILE206/rexxrtn.txt)
unxmit   - Ended   : 23:03:45 Elapsed : 0
*
Process 4488 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION 
(code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x0001003f7c48 
librexxapi.5.0.0.dylib`ApiConnection::~ApiConnection(this=0x000101500190) 
at CSStream.hpp:64
   61   {
   62   public:
   63   inline ApiConnection() : errcode(CSERROR_OK), messageBuffer(NULL) { 
}
-> 64   inline ~ApiConnection() { disconnect(); if (messageBuffer != NULL) 
{ free(messageBuffer); } }
   65   
   66   inline CSErrorCodeT getError()
   67   {
Target 0: (rexx) stopped.
(lldb) frame info
frame #0: 0x0001003f7c48 
librexxapi.5.0.0.dylib`ApiConnection::~ApiConnection(this=0x000101500190) 
at CSStream.hpp:64
(lldb) frame 0
invalid command 'frame 0'.
(lldb) frame select 0
frame #0: 0x0001003f7c48 
librexxapi.5.0.0.dylib`ApiConnection::~ApiConnection(this=0x000101500190) 
at CSStream.hpp:64
   61   {
   62   public:
   63   inline ApiConnection() : errcode(CSERROR_OK), messageBuffer(NULL) { 
}
-> 64   inline ~ApiConnection() { disconnect(); if (messageBuffer != NULL) 
{ free(messageBuffer); } }
   65   
   66   inline CSErrorCodeT getError()
   67   {
(lldb) frame variable
(SysLocalSocketConnection *) this = 0x000101500190
(lldb) quit
Quitting LLDB will kill one or more processes. Do you really want to proceed: 
[Y/n] Y
[enrico@enrico-imac zz]$


The interrupt occurs after a say “*"
When processing the exit instruction,
Changing the exit to a return did not change anything


And now the result with the test suite,
[enrico@enrico-imac ooRexx.tests.svn]$lldb -- rexx testOORexx.rex -s -X 
native_api
(lldb) target create "rexx"
Current executable set to 'rexx' (x86_64).
(lldb) settings set -- target.run-args  "testOORexx.rex" "-s" "-X" "native_api"
(lldb) r
Process 4562 launched: '/Users/enrico/rxapi/bin/rexx' (x86_64)
Searching for test containers
Executing automated test suite
Executing tests from .../enrico/ooRexx.tests.svn/ooRexx/SimpleTests.testGroup
Executing tests from .../ooRexx/extensions/hostemu/hostemu.testGroup
Executing tests from .../extensions/platform/unix/rxunixsys/SysUnix.testGroup
Executing tests from .../ooRexx/extensions/rxsock/socketClass.testGroup
Executing tests from .../ooRexx/extensions/rxregexp/rxregexp.testGroup
Executing tests from .../ooRexx.tests.svn/ooRexx/extensions/json/json.testGroup
Executing tests from .../ooRexx/extensions/rxmath/RxMath.testGroup
Executing tests from .../ooRexx/utilities/rxqueue/rxQueue.testGroup
Process 4562 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGPIPE
frame #0: 0x7fff711a9de2 libsystem_kernel.dylib`__sendto + 10
libsystem_kernel.dylib`__sendto:
->  0x7fff711a9de2 <+10>: jae0x7fff711a9dec; <+20>
0x7fff711a9de4 <+12>: movq   %rax, %rdi
0x7fff711a9de7 <+15>: jmp0x7fff711a0b0e; cerror
0x7fff711a9dec <+20>: retq   
Target 0: (rexx) stopped.
(lldb) frame info
frame #0: 0x7fff711a9de2 libsystem_kernel.dylib`__sendto + 10
(lldb) frame select 0
frame #0: 0x7fff711a9de2 libsystem_kernel.dylib`__sendto + 10
libsystem_kernel.dylib`__sendto:
->  0x7fff711a9de2 <+10>: jae0x7fff711a9dec; <+20>
0x7fff711a9de4 <+12>: movq   %rax, %rdi
0x7fff711a9de7 <+15>: jmp0x7fff711a0b0e; cerror
0x7fff711a9dec <+20>: retq   
(lldb) frame variable
(lldb) q


Do You have enough hints to proceed

E 



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[P.O. Jonsson]

Dear Enrico,

You could try to make a debug build and then use Valgrind 
 I think you can get it via Homebrew.

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



> Am 28.11.2018 um 22:10 schrieb Rick McGuire :
> 
> Well, I'm not familiar with the debuggers on a Mac, but use one to find out 
> the location of the exception and get a stack trace would be a good starting 
> point.
> 
> Rick
> 
> On Wed, Nov 28, 2018 at 4:06 PM Enrico Sorichetti via Oorexx-devel 
>  > wrote:
> Apple High Sierra
> 
> The build was successful
> 
> Started the test suite , but 
> 
> [enrico@enrico-imac ooRexx.tests.svn]$rexx testOORexx.rex -s -X native_api
> Searching for test containers...
> Executing automated test suite
> Executing tests from .../enrico/ooRexx.tests.svn/ooRexx/SimpleTests.testGroup
> Executing tests from .../ooRexx/extensions/hostemu/hostemu.testGroup
> Executing tests from .../extensions/platform/unix/rxunixsys/SysUnix.testGroup
> Executing tests from .../ooRexx/extensions/rxsock/socketClass.testGroup
> Executing tests from .../ooRexx/extensions/rxregexp/rxregexp.testGroup
> Executing tests from 
> .../ooRexx.tests.svn/ooRexx/extensions/json/json.testGroup
> Executing tests from .../ooRexx/extensions/rxmath/RxMath.testGroup
> Executing tests from .../ooRexx/utilities/rxqueue/rxQueue.testGroup
> Illegal instruction: 4
> 
> 
> Where do I start to debug it 
> 
> I AM NOT ASKING YOU TO DO IT, 
> I ASKING FOR A HINT ON HOW TO START
> 
> My best regards 
> 
> Dr. Enrico Sorichetti
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

Well, I'm not familiar with the debuggers on a Mac, but use one to find out
the location of the exception and get a stack trace would be a good
starting point.

Rick

On Wed, Nov 28, 2018 at 4:06 PM Enrico Sorichetti via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:

> Apple High Sierra
>
> The build was successful
>
> Started the test suite , but
>
> [enrico@enrico-imac ooRexx.tests.svn]$rexx testOORexx.rex -s -X native_api
> Searching for test containers...
> Executing automated test suite
> Executing tests from
> .../enrico/ooRexx.tests.svn/ooRexx/SimpleTests.testGroup
> Executing tests from .../ooRexx/extensions/hostemu/hostemu.testGroup
> Executing tests from
> .../extensions/platform/unix/rxunixsys/SysUnix.testGroup
> Executing tests from .../ooRexx/extensions/rxsock/socketClass.testGroup
> Executing tests from .../ooRexx/extensions/rxregexp/rxregexp.testGroup
> Executing tests from
> .../ooRexx.tests.svn/ooRexx/extensions/json/json.testGroup
> Executing tests from .../ooRexx/extensions/rxmath/RxMath.testGroup
> Executing tests from .../ooRexx/utilities/rxqueue/rxQueue.testGroup
> Illegal instruction: 4
>
>
> Where do I start to debug it
>
> I AM NOT ASKING YOU TO DO IT,
> I ASKING FOR A HINT ON HOW TO START
>
> My best regards
>
> Dr. Enrico Sorichetti
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Enrico Sorichetti via Oorexx-devel]

Apple High Sierra

The build was successful

Started the test suite , but 

[enrico@enrico-imac ooRexx.tests.svn]$rexx testOORexx.rex -s -X native_api
Searching for test containers...
Executing automated test suite
Executing tests from .../enrico/ooRexx.tests.svn/ooRexx/SimpleTests.testGroup
Executing tests from .../ooRexx/extensions/hostemu/hostemu.testGroup
Executing tests from .../extensions/platform/unix/rxunixsys/SysUnix.testGroup
Executing tests from .../ooRexx/extensions/rxsock/socketClass.testGroup
Executing tests from .../ooRexx/extensions/rxregexp/rxregexp.testGroup
Executing tests from .../ooRexx.tests.svn/ooRexx/extensions/json/json.testGroup
Executing tests from .../ooRexx/extensions/rxmath/RxMath.testGroup
Executing tests from .../ooRexx/utilities/rxqueue/rxQueue.testGroup
Illegal instruction: 4


Where do I start to debug it 

I AM NOT ASKING YOU TO DO IT, 
I ASKING FOR A HINT ON HOW TO START

My best regards 

Dr. Enrico Sorichetti

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

Wow, really? I have to admit that was somewhat unexpected! One thing that
needs to be checked out is what happens if a second version of rxapi gets
launched. You can test this by just issuing the rxapi command and checking
the return code. I was a little uncertain on what the expected result would
be with a second bind, and there's also some code to unlink() the file
before the bind operation that I'm hoping will fail if the socket is still
in use.

Rick

On Wed, Nov 28, 2018 at 3:44 PM Erich Steinböck 
wrote:

> The link error and Rony's compile errors should be resolved now.
>>
> With the latest commit, this builds without error and successfully runs
> all tests on Ubuntu 16.04
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Erich Steinböck]

>
> I checked it on my machine and it does indeed point to a user-specific
> directory where the user id is one segment of the path.

Same here on Ubuntu. $XDG_RUNTIME_DIR resolves to /run/user/1000 which is a
directory with the required 0700 access permission.
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Erich Steinböck]

>
> The link error and Rony's compile errors should be resolved now.
>
With the latest commit, this builds without error and successfully runs all
tests on Ubuntu 16.04
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Moritz Hoffmann]

I checked it on my machine and it does indeed point to a user-specific
directory where the user id is one segment of the path.
Moritz
On Wed, Nov 28, 2018 at 9:31 PM Rick McGuire  wrote:
>
> I'm hoping all of those MUST items are the responsibility of the OS and not 
> the application using that directory. Am I correct in understanding that 
> $XDG_RUNTIME_DIR is the user-specific directory, so all I need to do is place 
> the socket file there?
>
> Rick
>
> On Wed, Nov 28, 2018 at 1:20 PM Moritz Hoffmann  wrote:
>>
>> Further down it specifies that "it is mandatory that the directory continues 
>> to exist from his first login to his last logout on the system, and not 
>> removed in between." I would argue that as long as the daemon is running in 
>> the background the user is not fully logged out. At least this is how screen 
>> and tmux handle it.
>>
>> Moritz
>>
>> On Wed, Nov 28, 2018, 18:36 Erich Steinböck  
>> wrote:
>>>
>>> Should compile without error with latest commit.
>>> There's still a link error that needs to be resolved.  I checked the 
>>> rexxapi libray definition in CMakeLists.txt, but couldn't figure out what's 
>>> wrong.
>>> ~~~
>>> bin/librexxapi.so.5.0.0: undefined reference to 
>>> `SysServerLocalSocketConnectionManager::userServiceName'
>>> ~~~
>>>
>>>
 https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>>>
>>> says:"$XDG_RUNTIME_DIR defines the base directory relative to which 
>>> user-specific non-essential runtime files and other file objects (such as 
>>> sockets, named pipes, ...) should be stored. The directory MUST be owned by 
>>> the user, and he MUST be the only one having read and write access to it. 
>>> Its Unix access mode MUST be 0700.
>>>
>>> The lifetime of the directory MUST be bound to the user being logged in. It 
>>> MUST be created when the user first logs in and if the user fully logs out 
>>> the directory MUST be removed. If the user logs in more than once he should 
>>> get pointed to the same directory, and it is mandatory that the directory 
>>> continues to exist from his first login to his last logout on the system, 
>>> and not removed in between. Files in the directory MUST not survive reboot 
>>> or a full logout/login cycle. "
>>>
>>> Would that (see bold) mean that we couldn't keep a Rexx script running in 
>>> the background while logging out, because this would remove the socket?
>>>
>>> ___
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel



-- 
Moritz Hoffmann;
http://antiguru.de/


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

I'm hoping all of those MUST items are the responsibility of the OS and not
the application using that directory. Am I correct in understanding that
$XDG_RUNTIME_DIR is the user-specific directory, so all I need to do is
place the socket file there?

Rick

On Wed, Nov 28, 2018 at 1:20 PM Moritz Hoffmann  wrote:

> Further down it specifies that "it is mandatory that the directory
> continues to exist from his first login to his last logout on the system,
> and not removed in between." I would argue that as long as the daemon is
> running in the background the user is not fully logged out. At least this
> is how screen and tmux handle it.
>
> Moritz
>
> On Wed, Nov 28, 2018, 18:36 Erich Steinböck 
> wrote:
>
>> Should compile without error with latest commit.
>> There's still a link error that needs to be resolved.  I checked the
>> rexxapi libray definition in CMakeLists.txt, but couldn't figure out what's
>> wrong.
>> ~~~
>> bin/librexxapi.so.5.0.0: undefined reference to
>> `SysServerLocalSocketConnectionManager::userServiceName'
>> ~~~
>>
>>
>>
>>> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>>>
>> says:"$XDG_RUNTIME_DIR defines the base directory relative to which
>> user-specific non-essential runtime files and other file objects (such as
>> sockets, named pipes, ...) should be stored. The directory MUST be owned by
>> the user, and he MUST be the only one having read and write access to it.
>> Its Unix access mode MUST be 0700.
>>
>> * The lifetime of the directory MUST be bound to the user being logged in*.
>> It MUST be created when the user first logs in and if the user fully logs
>> out the directory MUST be removed. If the user logs in more than once he
>> should get pointed to the same directory, and it is mandatory that the
>> directory continues to exist from his first login to his last logout on the
>> system, and not removed in between. Files in the directory MUST not survive
>> reboot or a full logout/login cycle. "
>>
>> Would that (see bold) mean that we couldn't keep a Rexx script running in
>> the background while logging out, because this would remove the socket?
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

The link error and Rony's compile errors should be resolved now.

Rick

On Wed, Nov 28, 2018 at 12:36 PM Erich Steinböck 
wrote:

> Should compile without error with latest commit.
> There's still a link error that needs to be resolved.  I checked the
> rexxapi libray definition in CMakeLists.txt, but couldn't figure out what's
> wrong.
> ~~~
> bin/librexxapi.so.5.0.0: undefined reference to
> `SysServerLocalSocketConnectionManager::userServiceName'
> ~~~
>
>
>
>> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>>
> says:"$XDG_RUNTIME_DIR defines the base directory relative to which
> user-specific non-essential runtime files and other file objects (such as
> sockets, named pipes, ...) should be stored. The directory MUST be owned by
> the user, and he MUST be the only one having read and write access to it.
> Its Unix access mode MUST be 0700.
>
> * The lifetime of the directory MUST be bound to the user being logged in*.
> It MUST be created when the user first logs in and if the user fully logs
> out the directory MUST be removed. If the user logs in more than once he
> should get pointed to the same directory, and it is mandatory that the
> directory continues to exist from his first login to his last logout on the
> system, and not removed in between. Files in the directory MUST not survive
> reboot or a full logout/login cycle. "
>
> Would that (see bold) mean that we couldn't keep a Rexx script running in
> the background while logging out, because this would remove the socket?
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Moritz Hoffmann]

Further down it specifies that "it is mandatory that the directory
continues to exist from his first login to his last logout on the system,
and not removed in between." I would argue that as long as the daemon is
running in the background the user is not fully logged out. At least this
is how screen and tmux handle it.

Moritz

On Wed, Nov 28, 2018, 18:36 Erich Steinböck 
wrote:

> Should compile without error with latest commit.
> There's still a link error that needs to be resolved.  I checked the
> rexxapi libray definition in CMakeLists.txt, but couldn't figure out what's
> wrong.
> ~~~
> bin/librexxapi.so.5.0.0: undefined reference to
> `SysServerLocalSocketConnectionManager::userServiceName'
> ~~~
>
>
>
>> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>>
> says:"$XDG_RUNTIME_DIR defines the base directory relative to which
> user-specific non-essential runtime files and other file objects (such as
> sockets, named pipes, ...) should be stored. The directory MUST be owned by
> the user, and he MUST be the only one having read and write access to it.
> Its Unix access mode MUST be 0700.
>
> * The lifetime of the directory MUST be bound to the user being logged in*.
> It MUST be created when the user first logs in and if the user fully logs
> out the directory MUST be removed. If the user logs in more than once he
> should get pointed to the same directory, and it is mandatory that the
> directory continues to exist from his first login to his last logout on the
> system, and not removed in between. Files in the directory MUST not survive
> reboot or a full logout/login cycle. "
>
> Would that (see bold) mean that we couldn't keep a Rexx script running in
> the background while logging out, because this would remove the socket?
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rony G. Flatscher]

Forgot to mention: I always wipe out the working directory such that no old 
artefacts remain and
such that the CMake files get created from scratch.

---rony


On 28.11.2018 18:48, Rony G. Flatscher wrote:
>
> rev 11537, Ubuntu:
>
> [  0%] Generating rxsubcom.1.gz
> [  0%] Built target rxsubcom_man
> [  7%] Built target rexxapi
> [ 71%] Built target rexx
> [ 72%] Building CXX object 
> CMakeFiles/rxapi.dir/rexxapi/server/platform/unix/linux/APIService.cpp.o
> 
> /home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:
>  In function ´int main(int, char**)`:
> 
> /home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:95:9:
>  error: ´SysServerLocalSocketConnectionManager` was not declared in this scope
>  SysServerLocalSocketConnectionManager *c = new 
> SysServerLocalSocketConnectionManager();
>  ^
> 
> /home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:95:48:
>  error: ´c` was not declared in this scope
>  SysServerLocalSocketConnectionManager *c = new 
> SysServerLocalSocketConnectionManager();
> ^
> 
> /home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:95:56:
>  error: expected type-specifier before ´SysServerLocalSocketConnectionManager`
>  SysServerLocalSocketConnectionManager *c = new 
> SysServerLocalSocketConnectionManager();
> ^
> 
> /home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:98:22:
>  error: ´SysServerLocalSocketConnectionManager` is not a class or namespace
>  if 
> (!c->bind(SysServerLocalSocketConnectionManager::generateServiceName()))
>   ^
> 
> /home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:100:20:
>  error: type ´` argument given to ´delete`, expected pointer
>  delete c;
> ^
> 
> /home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:101:20:
>  error: ´EACCESS` was not declared in this scope
>  return EACCESS;
> ^
> 
> /home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:103:30:
>  error: no matching function for call to ´APIServer::initServer()`
>  apiServer.initServer();   // start up the server
>   ^
> In file included from 
> /home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:50:0:
> 
> /home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/APIServer.hpp:59:10:
>  note: candidate: void APIServer::initServer(ServerConnectionManager*)
>  void initServer(ServerConnectionManager *c);
>   ^
> 
> /home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/APIServer.hpp:59:10:
>  note:   candidate expects 1 argument, 0 provided
> CMakeFiles/rxapi.dir/build.make:422: recipe for target 
> 'CMakeFiles/rxapi.dir/rexxapi/server/platform/unix/linux/APIService.cpp.o' 
> failed
> make[2]: *** 
> [CMakeFiles/rxapi.dir/rexxapi/server/platform/unix/linux/APIService.cpp.o] 
> Error 1
> CMakeFiles/Makefile2:105: recipe for target 'CMakeFiles/rxapi.dir/all' 
> failed
> make[1]: *** [CMakeFiles/rxapi.dir/all] Error 2
> Makefile:149: recipe for target 'all' failed
> make: *** [all] Error 2
>
> ---rony
>
> On 28.11.2018 18:35, Erich Steinböck wrote:
>> Should compile without error with latest commit.
>> There's still a link error that needs to be resolved.  I checked the rexxapi 
>> libray definition in
>> CMakeLists.txt, but couldn't figure out what's wrong.
>> ~~~
>> bin/librexxapi.so.5.0.0: undefined reference to
>> `SysServerLocalSocketConnectionManager::userServiceName'
>> ~~~
>>
>>
>> 
>> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>>
>> says:"|$XDG_RUNTIME_DIR| defines the base directory relative to which 
>> user-specific non-essential
>> runtime files and other file objects (such as sockets, named pipes, ...) 
>> should be stored. The
>> directory MUST be owned by the user, and he MUST be the only one having read 
>> and write access to
>> it. Its Unix access mode MUST be 0700.
>>
>> *The lifetime of the directory MUST be bound to the user being logged in*. 
>> It MUST be created
>> when the user first logs in and if the user fully logs out the directory 
>> MUST be removed. If the
>> user logs in more than once he should get pointed to the same directory, and 
>> it is mandatory that
>> the directory continues to exist from his first login to his last logout on 
>> the system, and not
>> removed in between. 

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Enrico Sorichetti via Oorexx-devel]

Same on apple High Sierra 


> On 28 Nov 2018, at 18:35, Erich Steinböck  wrote:
> 
> Should compile without error with latest commit.
> There's still a link error that needs to be resolved.  I checked the rexxapi 
> libray definition in CMakeLists.txt, but couldn't figure out what's wrong.
> ~~~
> bin/librexxapi.so.5.0.0: undefined reference to 
> `SysServerLocalSocketConnectionManager::userServiceName'
> ~~~
> 
> 
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html 
> 
>  
> says:"$XDG_RUNTIME_DIR defines the base directory relative to which 
> user-specific non-essential runtime files and other file objects (such as 
> sockets, named pipes, ...) should be stored. The directory MUST be owned by 
> the user, and he MUST be the only one having read and write access to it. Its 
> Unix access mode MUST be 0700.
> The lifetime of the directory MUST be bound to the user being logged in. It 
> MUST be created when the user first logs in and if the user fully logs out 
> the directory MUST be removed. If the user logs in more than once he should 
> get pointed to the same directory, and it is mandatory that the directory 
> continues to exist from his first login to his last logout on the system, and 
> not removed in between. Files in the directory MUST not survive reboot or a 
> full logout/login cycle. "
> 
> Would that (see bold) mean that we couldn't keep a Rexx script running in the 
> background while logging out, because this would remove the socket?
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rony G. Flatscher]

rev 11537, Ubuntu:

[  0%] Generating rxsubcom.1.gz
[  0%] Built target rxsubcom_man
[  7%] Built target rexxapi
[ 71%] Built target rexx
[ 72%] Building CXX object 
CMakeFiles/rxapi.dir/rexxapi/server/platform/unix/linux/APIService.cpp.o

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:
 In function ´int main(int, char**)`:

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:95:9:
 error: ´SysServerLocalSocketConnectionManager` was not declared in this scope
 SysServerLocalSocketConnectionManager *c = new 
SysServerLocalSocketConnectionManager();
 ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:95:48:
 error: ´c` was not declared in this scope
 SysServerLocalSocketConnectionManager *c = new 
SysServerLocalSocketConnectionManager();
^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:95:56:
 error: expected type-specifier before ´SysServerLocalSocketConnectionManager`
 SysServerLocalSocketConnectionManager *c = new 
SysServerLocalSocketConnectionManager();
^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:98:22:
 error: ´SysServerLocalSocketConnectionManager` is not a class or namespace
 if 
(!c->bind(SysServerLocalSocketConnectionManager::generateServiceName()))
  ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:100:20:
 error: type ´` argument given to ´delete`, expected pointer
 delete c;
^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:101:20:
 error: ´EACCESS` was not declared in this scope
 return EACCESS;
^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:103:30:
 error: no matching function for call to ´APIServer::initServer()`
 apiServer.initServer();   // start up the server
  ^
In file included from 
/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:50:0:

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/APIServer.hpp:59:10:
 note: candidate: void APIServer::initServer(ServerConnectionManager*)
 void initServer(ServerConnectionManager *c);
  ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/APIServer.hpp:59:10:
 note:   candidate expects 1 argument, 0 provided
CMakeFiles/rxapi.dir/build.make:422: recipe for target 
'CMakeFiles/rxapi.dir/rexxapi/server/platform/unix/linux/APIService.cpp.o' 
failed
make[2]: *** 
[CMakeFiles/rxapi.dir/rexxapi/server/platform/unix/linux/APIService.cpp.o] 
Error 1
CMakeFiles/Makefile2:105: recipe for target 'CMakeFiles/rxapi.dir/all' 
failed
make[1]: *** [CMakeFiles/rxapi.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

---rony

On 28.11.2018 18:35, Erich Steinböck wrote:
> Should compile without error with latest commit.
> There's still a link error that needs to be resolved.  I checked the rexxapi 
> libray definition in
> CMakeLists.txt, but couldn't figure out what's wrong.
> ~~~
> bin/librexxapi.so.5.0.0: undefined reference to
> `SysServerLocalSocketConnectionManager::userServiceName'
> ~~~
>
>
> 
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>
> says:"|$XDG_RUNTIME_DIR| defines the base directory relative to which 
> user-specific non-essential
> runtime files and other file objects (such as sockets, named pipes, ...) 
> should be stored. The
> directory MUST be owned by the user, and he MUST be the only one having read 
> and write access to
> it. Its Unix access mode MUST be 0700.
>
> *The lifetime of the directory MUST be bound to the user being logged in*. It 
> MUST be created when
> the user first logs in and if the user fully logs out the directory MUST be 
> removed. If the user
> logs in more than once he should get pointed to the same directory, and it is 
> mandatory that the
> directory continues to exist from his first login to his last logout on the 
> system, and not
> removed in between. Files in the directory MUST not survive reboot or a full 
> logout/login cycle. "
>
> Would that (see bold) mean that we couldn't keep a Rexx script running in the 
> background while
> logging out, because this would remove the socket?
>

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Erich Steinböck]

Should compile without error with latest commit.
There's still a link error that needs to be resolved.  I checked the
rexxapi libray definition in CMakeLists.txt, but couldn't figure out what's
wrong.
~~~
bin/librexxapi.so.5.0.0: undefined reference to
`SysServerLocalSocketConnectionManager::userServiceName'
~~~


https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>
says:"$XDG_RUNTIME_DIR defines the base directory relative to which
user-specific non-essential runtime files and other file objects (such as
sockets, named pipes, ...) should be stored. The directory MUST be owned by
the user, and he MUST be the only one having read and write access to it.
Its Unix access mode MUST be 0700.

* The lifetime of the directory MUST be bound to the user being logged in*.
It MUST be created when the user first logs in and if the user fully logs
out the directory MUST be removed. If the user logs in more than once he
should get pointed to the same directory, and it is mandatory that the
directory continues to exist from his first login to his last logout on the
system, and not removed in between. Files in the directory MUST not survive
reboot or a full logout/login cycle. "

Would that (see bold) mean that we couldn't keep a Rexx script running in
the background while logging out, because this would remove the socket?
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Moritz Hoffmann]

Great! Looking at the changes I noticed the socket is created in
$HOME. I think we should use HOME only as a fall-back if the proper
location is not available. The proper location is specified by the XDG
spec [1] to be $XDG_RUNTIME_DIR. That way the socket cannot leak to
other users because permissions are managed by the OS.

Also, still some compile errors, some fixed by this patch:
diff --git a/rexxapi/common/platform/unix/SysCSStream.cpp
b/rexxapi/common/platform/unix/SysCSStream.cpp
index 028910d..e2375aa 100644
--- a/rexxapi/common/platform/unix/SysCSStream.cpp
+++ b/rexxapi/common/platform/unix/SysCSStream.cpp
@@ -51,7 +51,8 @@
 #include 
 #include 
 #include 
-#include "sys/un.h"
+#include 
+#include 

 #if defined( HAVE_STRINGS_H )
 # include 
@@ -450,7 +451,7 @@ const char
*SysServerLocalSocketConnectionManager::generateServiceName()
 // if we can't get the home path from getenv(), fall back on getpwuid()
 if ( (homePath = getenv("HOME")) == NULL)
 {
-homepath = getpwuid(getuid())->pw_dir;
+homePath = getpwuid(getuid())->pw_dir;
 }

 // this creates a hidden file in the user's home directory.

Remaining ones:
[  0%] Generating rxsubcom.1.gz
[  0%] Built target rxsubcom_man
[  0%] Building CXX object
CMakeFiles/rexxapi.dir/rexxapi/common/platform/unix/SysCSStream.cpp.o
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:
In member function ‘bool SysLocalSocketConnection::connect(const
char*)’:
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:257:33:
error: expected primary-expression before ‘struct’
 socklen_t size = (offsetof (struct sockaddr_un, sun_path)
 ^~
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:257:53:
error: ‘sun_path’ was not declared in this scope
 socklen_t size = (offsetof (struct sockaddr_un, sun_path)
 ^~~~
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:257:61:
error: ‘offsetof’ was not declared in this scope
 socklen_t size = (offsetof (struct sockaddr_un, sun_path)
 ^
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:
In member function ‘bool
SysServerLocalSocketConnectionManager::bind(const char*)’:
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:357:30:
error: expected primary-expression before ‘struct’
 size_t size = (offsetof (struct sockaddr_un, sun_path)
  ^~
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:357:50:
error: ‘sun_path’ was not declared in this scope
 size_t size = (offsetof (struct sockaddr_un, sun_path)
  ^~~~
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:357:58:
error: ‘offsetof’ was not declared in this scope
 size_t size = (offsetof (struct sockaddr_un, sun_path)
  ^
CMakeFiles/rexxapi.dir/build.make:566: recipe for target
'CMakeFiles/rexxapi.dir/rexxapi/common/platform/unix/SysCSStream.cpp.o'
failed
make[2]: *** 
[CMakeFiles/rexxapi.dir/rexxapi/common/platform/unix/SysCSStream.cpp.o]
Error 1
CMakeFiles/Makefile2:444: recipe for target 'CMakeFiles/rexxapi.dir/all' failed
make[1]: *** [CMakeFiles/rexxapi.dir/all] Error 2
Makefile:151: recipe for target 'all' failed
make: *** [all] Error 2

Keep up the great work :)
Moritz

[1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
On Wed, Nov 28, 2018 at 3:23 PM Rick McGuire  wrote:
>
> Thanks, most of these should be fixed but a couple of the errors puzzled me. 
> Let's see if they go away.
>
> Rick
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel



-- 
Moritz Hoffmann;
http://antiguru.de/


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[René Jansen]

Hi Enrico,

thanks, I did not know that. Before I attempt it, I will setup a job on our 
build Jenkins that builds the sandbox.

best regards,

René.


> On 28 Nov 2018, at 11:47, Enrico Sorichetti via Oorexx-devel 
>  wrote:
> 
> 
> 
>> On 28 Nov 2018, at 16:32, Rick McGuire > > wrote:
>> 
>> Also not going to happen. I'm not a Linux user, I don't like the tooling on 
>> the system (editors, debuggers, etc.) If this is going to be done, it will 
>> be because the community of people who do run on those systems help to make 
>> it happen, not because I am expected to do all of the work. 
> 
> Nobody is asking/expecting You to do that, You certainly agree that
> The back and forth for simple compilation errors is pretty annoying
> 
> The alternative just to check for clean builds would be to have a repository
>  On GitHub  activating the option for travis CI
> 
> No need to learn unix/bsd 
> You/somebody will just have to add a couple of files to trigger the travis 
> jobs
> 
> It even supports apple builds 
> 
> Enrico
> 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

On Wed, Nov 28, 2018 at 10:48 AM Enrico Sorichetti via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:

>
>
> On 28 Nov 2018, at 16:32, Rick McGuire  wrote:
>
> Also not going to happen. I'm not a Linux user, I don't like the tooling
> on the system (editors, debuggers, etc.) If this is going to be done, it
> will be because the community of people who do run on those systems help to
> make it happen, not because I am expected to do all of the work.
>
>
> Nobody is asking/expecting You to do that, You certainly agree that
> The back and forth for simple compilation errors is pretty annoying
>
> The alternative just to check for clean builds would be to have a
> repository
>  On GitHub  activating the option for travis CI
>
> No need to learn unix/bsd
> You/somebody will just have to add a couple of files to trigger the travis
> jobs
>
>
And that someone is not going to be me. If you find this annoying, then
feel free to actually take a stab at fixing the errors rather than just
reporting the errors and waiting for me to fix them.

Rick



> It even supports apple builds
>
> Enrico
>
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Enrico Sorichetti via Oorexx-devel]

> On 28 Nov 2018, at 16:32, Rick McGuire  wrote:
> 
> Also not going to happen. I'm not a Linux user, I don't like the tooling on 
> the system (editors, debuggers, etc.) If this is going to be done, it will be 
> because the community of people who do run on those systems help to make it 
> happen, not because I am expected to do all of the work. 

Nobody is asking/expecting You to do that, You certainly agree that
The back and forth for simple compilation errors is pretty annoying

The alternative just to check for clean builds would be to have a repository
 On GitHub  activating the option for travis CI

No need to learn unix/bsd 
You/somebody will just have to add a couple of files to trigger the travis jobs

It even supports apple builds 

Enrico




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rony G. Flatscher]

Revision 11535l, Ubuntu:

[  0%] Generating rxsubcom.1.gz
[  0%] Built target rxsubcom_man
[  0%] Building CXX object 
CMakeFiles/rexxapi.dir/rexxapi/common/platform/unix/SysCSStream.cpp.o

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:
 In member function ´bool SysLocalSocketConnection::connect(const char*)`:

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:249:24:
 error: aggregate ´SysLocalSocketConnection::connect(const char*)::sockaddr_un 
name` has incomplete type and cannot be defined
 struct sockaddr_un name; // address structure
^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:255:33:
 error: expected primary-expression before ´struct`
 socklen_t size = (offsetof (struct sockaddr_un, sun_path)
 ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:255:53:
 error: ´sun_path` was not declared in this scope
 socklen_t size = (offsetof (struct sockaddr_un, sun_path)
 ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:255:61:
 error: ´offsetof` was not declared in this scope
 socklen_t size = (offsetof (struct sockaddr_un, sun_path)
 ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:
 In member function ´bool SysServerLocalSocketConnectionManager::bind(const 
char*)`:

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:349:24:
 error: aggregate ´SysServerLocalSocketConnectionManager::bind(const 
char*)::sockaddr_un name` has incomplete type and cannot be defined
 struct sockaddr_un name; // address structure
^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:355:30:
 error: expected primary-expression before ´struct`
 size_t size = (offsetof (struct sockaddr_un, sun_path)
  ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:355:50:
 error: ´sun_path` was not declared in this scope
 size_t size = (offsetof (struct sockaddr_un, sun_path)
  ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:355:58:
 error: ´offsetof` was not declared in this scope
 size_t size = (offsetof (struct sockaddr_un, sun_path)
  ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:
 In static member function ´static const char* 
SysServerLocalSocketConnectionManager::generateServiceName()`:

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:448:5:
 error: expected initializer before ´if`
 if ( (homePath = getenv("HOME")) == NULL)
 ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:453:88:
 error: ´homePath` was not declared in this scope
 snprintf(pipeNameBuffer, sizeof(pipeNameBuffer), 
"%s/.ooRexx-%d.%d.%d-%s.service", homePath, ORX_VER, ORX_REL, ORX_MOD,

^
CMakeFiles/rexxapi.dir/build.make:566: recipe for target 
'CMakeFiles/rexxapi.dir/rexxapi/common/platform/unix/SysCSStream.cpp.o' failed
make[2]: *** 
[CMakeFiles/rexxapi.dir/rexxapi/common/platform/unix/SysCSStream.cpp.o] Error 1
CMakeFiles/Makefile2:444: recipe for target 'CMakeFiles/rexxapi.dir/all' 
failed
make[1]: *** [CMakeFiles/rexxapi.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

---rony

On 28.11.2018 15:22, Rick McGuire wrote:
> Thanks, most of these should be fixed but a couple of the errors puzzled me. 
> Let's see if they go
> away.
>
> Rick

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

Also not going to happen. I'm not a Linux user, I don't like the tooling on
the system (editors, debuggers, etc.) If this is going to be done, it will
be because the community of people who do run on those systems help to make
it happen, not because I am expected to do all of the work.

Rick

On Wed, Nov 28, 2018 at 10:29 AM René Jansen  wrote:

> Another alternative would be a Docker image on your local windows box; I
> can set up a development image for your sandbox in half an hour or so.
>
> René.
>
> On 28 Nov 2018, at 09:48, Rick McGuire  wrote:
>
> Nope, I don't do remote access for debugging.
>
> Rick
>
> On Wed, Nov 28, 2018 at 8:47 AM Erich Steinböck <
> erich.steinbo...@gmail.com> wrote:
>
>> I don't have access to any linux systems now
>>>
>> Rick, if you'd like so, I can give you access to an Ubuntu VM that is
>> used for ooRexx Jenkins builds,
>> It's already fully set up for building.
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[René Jansen]

Another alternative would be a Docker image on your local windows box; I can 
set up a development image for your sandbox in half an hour or so.

René.

> On 28 Nov 2018, at 09:48, Rick McGuire  wrote:
> 
> Nope, I don't do remote access for debugging. 
> 
> Rick
> 
> On Wed, Nov 28, 2018 at 8:47 AM Erich Steinböck  > wrote:
> I don't have access to any linux systems now 
> Rick, if you'd like so, I can give you access to an Ubuntu VM that is used 
> for ooRexx Jenkins builds,
> It's already fully set up for building.
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rony G. Flatscher]

Here from Ubuntu, rev 11534:

[  0%] Generating rxsubcom.1.gz
[  0%] Built target rxsubcom_man
[  0%] Building CXX object 
CMakeFiles/rexxapi.dir/rexxapi/common/platform/unix/SysCSStream.cpp.o

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:
 In member function ´bool SysLocalSocketConnection::connect(const char*)`:

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:251:64:
 error: cannot convert ´in_addr` to ´char*` for argument ´1` to ´char* 
strncpy(char*, const char*, size_t)`
 strncpy (name.sin_addr, serviceName, sizeof (name.sin_addr));
^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:253:18:
 error: no match for ´operator[]` (operand types are ´in_addr` and ´long 
unsigned int`)
 name.sin_addr[sizeof (name.sin_addr) - 1] = '\0';
  ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:255:33:
 error: expected primary-expression before ´struct`
 socklen_t size = (offsetof (struct sockaddr_un, sin_addr)
 ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:255:53:
 error: ´sin_addr` was not declared in this scope
 socklen_t size = (offsetof (struct sockaddr_un, sin_addr)
 ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:255:61:
 error: ´offsetof` was not declared in this scope
 socklen_t size = (offsetof (struct sockaddr_un, sin_addr)
 ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:256:34:
 error: cannot convert ´in_addr` to ´const char*` for argument ´1` to ´size_t 
strlen(const char*)`
   + strlen (name.sin_addr));
  ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:
 In member function ´virtual bool 
SysServerSocketConnectionManager::disconnect()`:

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:317:22:
 error: ´userServiceName` was not declared in this scope
 free((void *)userServiceName);
  ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:
 In member function ´bool SysServerLocalSocketConnectionManager::bind(const 
char*)`:

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:356:64:
 error: cannot convert ´in_addr` to ´char*` for argument ´1` to ´char* 
strncpy(char*, const char*, size_t)`
 strncpy (name.sin_addr, serviceName, sizeof (name.sin_addr));
^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:358:18:
 error: no match for ´operator[]` (operand types are ´in_addr` and ´long 
unsigned int`)
 name.sin_addr[sizeof (name.sin_addr) - 1] = '\0';
  ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:360:30:
 error: expected primary-expression before ´struct`
 size_t size = (offsetof (struct sockaddr_un, sin_addr)
  ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:360:50:
 error: ´sin_addr` was not declared in this scope
 size_t size = (offsetof (struct sockaddr_un, sin_addr)
  ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:360:58:
 error: ´offsetof` was not declared in this scope
 size_t size = (offsetof (struct sockaddr_un, sin_addr)
  ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:361:34:
 error: cannot convert ´in_addr` to ´const char*` for argument ´1` to ´size_t 
strlen(const char*)`
   + strlen (name.sin_addr));
  ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:
 At global scope:

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:439:69:
 error: no ´const char* 
SysServerLocalSocketConnectionManager::generatePipeName()` member function 
declared in class ´SysServerLocalSocketConnectionManager`
 const char *SysServerLocalSocketConnectionManager::generatePipeName()
  

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

Thanks, most of these should be fixed but a couple of the errors puzzled
me. Let's see if they go away.

Rick
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Moritz Hoffmann]

closesocket -> close

[  0%] Generating rxsubcom.1.gz
[  0%] Built target rxsubcom_man
[  0%] Building CXX object
CMakeFiles/rexxapi.dir/rexxapi/common/platform/unix/SysCSStream.cpp.o
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:
In member function ‘virtual bool SysSocketConnection::disconnect()’:
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:198:22:
error: ‘closesocket’ was not declared in this scope
 closesocket(c);
  ^
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:
In member function ‘bool SysLocalSocketConnection::connect(const
char*)’:
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:249:10:
error: ‘struct sockaddr_in’ has no member named ‘sun_family’; did you
mean ‘sin_family’?
 name.sun_family = AF_LOCAL;
  ^~
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:250:19:
error: ‘struct sockaddr_in’ has no member named ‘sun_path’; did you
mean ‘sin_port’?
 strncpy (name.sun_path, serviceName, sizeof (name.sun_path));
   ^~~~
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:250:55:
error: ‘struct sockaddr_in’ has no member named ‘sun_path’; did you
mean ‘sin_port’?
 strncpy (name.sun_path, serviceName, sizeof (name.sun_path));
   ^~~~
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:252:10:
error: ‘struct sockaddr_in’ has no member named ‘sun_path’; did you
mean ‘sin_port’?
 name.sun_path[sizeof (name.sun_path) - 1] = '\0';
  ^~~~
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:252:32:
error: ‘struct sockaddr_in’ has no member named ‘sun_path’; did you
mean ‘sin_port’?
 name.sun_path[sizeof (name.sun_path) - 1] = '\0';
^~~~
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:254:30:
error: expected primary-expression before ‘struct’
 size_t size = (offsetof (struct sockaddr_un, sun_path)
  ^~
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:254:50:
error: ‘sun_path’ was not declared in this scope
 size_t size = (offsetof (struct sockaddr_un, sun_path)
  ^~~~
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:254:58:
error: ‘offsetof’ was not declared in this scope
 size_t size = (offsetof (struct sockaddr_un, sun_path)
  ^
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:255:26:
error: ‘struct sockaddr_in’ has no member named ‘sun_path’; did you
mean ‘sin_port’?
   + strlen (name.sun_path));
  ^~~~
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:260:22:
error: ‘closesocket’ was not declared in this scope
 closesocket(c);
  ^
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:
In member function ‘virtual ApiConnection*
SysServerSocketConnectionManager::acceptConnection()’:
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:285:55:
error: invalid conversion from ‘int*’ to ‘socklen_t* {aka unsigned
int*}’ [-fpermissive]
 int client = accept(c, (struct sockaddr *) , );
   ^~~
In file included from
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:48:0:
/usr/include/x86_64-linux-gnu/sys/socket.h:243:12: note:
initializing argument 3 of ‘int accept(int, sockaddr*, socklen_t*)’
 extern int accept (int __fd, __SOCKADDR_ARG __addr,
^~
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:
In member function ‘virtual bool
SysServerSocketConnectionManager::disconnect()’:
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:307:22:
error: ‘closesocket’ was not declared in this scope
 closesocket(c);
  ^
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:316:22:
error: ‘userServiceName’ was not declared in this scope
 free((void *)userServiceName);
  ^~~
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:
In member function ‘bool
SysServerLocalSocketConnectionManager::bind(const char*)’:
/home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp:354:10:
error: ‘struct sockaddr_in’ has no member named ‘sun_family’; did you
mean ‘sin_family’?
 name.sun_family = AF_LOCAL;
  ^~

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

Hmmm, I was able to fix a couple of the errors here, but the bulk of them
are quite puzzling. The types in question are all defined in
SysCSStream.hpp, which is included in the .cpp file. Even more puzzling,
there are references to types defined in CSStream.hpp, which is NOT
included in the .cpp source. I have no idea as to what is going on here.

Rick
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

Nope, I don't do remote access for debugging.

Rick

On Wed, Nov 28, 2018 at 8:47 AM Erich Steinböck 
wrote:

> I don't have access to any linux systems now
>>
> Rick, if you'd like so, I can give you access to an Ubuntu VM that is used
> for ooRexx Jenkins builds,
> It's already fully set up for building.
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Enrico Sorichetti via Oorexx-devel]

> On 28 Nov 2018, at 13:42, Rick McGuire  wrote:
> 
> Thanks, fixes checked in. 
> 
> Rick
> 
> On Wed, Nov 28, 2018 at 7:32 AM Enrico Sorichetti via Oorexx-devel 
>  > wrote:

SysCSSStream.cpp and CSSStream naming mismatch

Used the right name but got more errors 


/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:71:6: 
error: use of undeclared identifier 'SysSocketConnection'
bool SysSocketConnection::read(void *buf, size_t bufsize, size_t *bytesread)
 ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:102:6: 
error: use of undeclared identifier 'SysSocketConnection'
bool SysSocketConnection::write(void *buf, size_t bufsize, size_t *byteswritten)
 ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:133:6: 
error: use of undeclared identifier 'SysSocketConnection'
bool SysSocketConnection::write(void *buf, size_t bufsize, void *buf2, size_t 
buf2size, size_t *byteswritten)
 ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:194:6: 
error: use of undeclared identifier 'SysSocketConnection'
bool SysSocketConnection::disconnect()
 ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:217:1: 
error: use of undeclared identifier 'SysLocalSocketConnection'
SysLocalSocketConnection::SysLocalSocketConnection(const char *serviceName) : 
SysSocketConnection()
^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:230:6: 
error: use of undeclared identifier 'SysLocalSocketConnection'
bool SysLocalSocketConnection::connect(const char *serviceName)
 ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:275:16: 
error: use of undeclared identifier 'SysServerSocketConnectionManager';
  did you mean 'ServerConnectionManager'?
ApiConnection *SysServerSocketConnectionManager::acceptConnection()
   ^~~~
   ServerConnectionManager
/Users/enrico/rxapi.src/rexxapi/common/CSStream.hpp:102:7: note: 
'ServerConnectionManager' declared here
class ServerConnectionManager
  ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:280:9: 
error: use of undeclared identifier 'c'
if (c == -1)
^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:285:5: 
error: unknown type name 'SOCKET'
SOCKET client = accept(c, (struct sockaddr *) , );
^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:285:28: 
error: use of undeclared identifier 'c'
SOCKET client = accept(c, (struct sockaddr *) , );
   ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:294:16: 
error: unknown type name 'SysSocketConnection'
return new SysSocketConnection(client);
   ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:303:6: 
error: use of undeclared identifier 'SysServerSocketConnectionManager';
  did you mean 'ServerConnectionManager'?
bool SysServerSocketConnectionManager::disconnect()
 ^~~~
 ServerConnectionManager
/Users/enrico/rxapi.src/rexxapi/common/CSStream.hpp:102:7: note: 
'ServerConnectionManager' declared here
class ServerConnectionManager
  ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:303:40: 
error: redefinition of 'disconnect'
bool SysServerSocketConnectionManager::disconnect()
   ^
/Users/enrico/rxapi.src/rexxapi/common/CSStream.hpp:117:18: note: previous 
definition is here
virtual bool disconnect() { return false; };
 ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:305:9: 
error: use of undeclared identifier 'c'
if (c != -1)
^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:307:21: 
error: use of undeclared identifier 'c'
closesocket(c);
^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:308:9: 
error: use of undeclared identifier 'c'
c = -1;
^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:310:16: 
error: use of undeclared identifier 'boundServiceName'
unlink(boundServiceName);
   ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:311:9: 
error: use of undeclared identifier 'boundServiceName'
boundServiceName = NULL;
^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:316:22: 
error: use of undeclared identifier 'userServiceName'
free((void *)userServiceName);
 ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.


BTW I am testing on apple
cheers
Enrico


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rick McGuire]

Thanks, fixes checked in.

Rick

On Wed, Nov 28, 2018 at 7:32 AM Enrico Sorichetti via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:

>
>
> On 28 Nov 2018, at 13:23, Rick McGuire  wrote:
>
> https://svn.code.sf.net/p/oorexx/code-0/sandbox/rick/rxapi
>
>
>
> Just tried it , got
>
> [  6%] Building CXX object
> CMakeFiles/rexxapi.dir/rexxapi/client/platform/unix/SysLocalAPIManager.cpp.o
> In file included from
> /Users/enrico/rxapi.src/rexxapi/client/platform/unix/SysLocalAPIManager.cpp:44:
> /Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.hpp:75:6:
> error: expected the class name after '~' to name a destructor
> ~SysInetSocketConnection();
>  ^~~
>  SysLocalSocketConnection
> /Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.hpp:106:12:
> error: missing return type for function
>   'SysServerLocalInetSocketConnectionManager'; did you mean the
> constructor name 'SysServerLocalSocketConnectionManager'?
> inline SysServerLocalInetSocketConnectionManager() { }
>^
>SysServerLocalSocketConnectionManager
> /Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.hpp:117:10:
> error: expected ';' at end of declaration list
> const char *boundServiceName;// the service name this instance
> is bound to.
>  ^
>  ;
> 3 errors generated.
>
> Cheers
> Enrico
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Enrico Sorichetti via Oorexx-devel]

> On 28 Nov 2018, at 13:23, Rick McGuire  wrote:
> 
> https://svn.code.sf.net/p/oorexx/code-0/sandbox/rick/rxapi 
> 

Just tried it , got 

[  6%] Building CXX object 
CMakeFiles/rexxapi.dir/rexxapi/client/platform/unix/SysLocalAPIManager.cpp.o
In file included from 
/Users/enrico/rxapi.src/rexxapi/client/platform/unix/SysLocalAPIManager.cpp:44:
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.hpp:75:6: 
error: expected the class name after '~' to name a destructor
~SysInetSocketConnection();
 ^~~
 SysLocalSocketConnection
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.hpp:106:12: 
error: missing return type for function
  'SysServerLocalInetSocketConnectionManager'; did you mean the constructor 
name 'SysServerLocalSocketConnectionManager'?
inline SysServerLocalInetSocketConnectionManager() { }
   ^
   SysServerLocalSocketConnectionManager
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.hpp:117:10: 
error: expected ';' at end of declaration list
const char *boundServiceName;// the service name this instance is 
bound to.
 ^
 ;
3 errors generated.

Cheers
Enrico

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel