Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Gil Barmwater 
Yes, as a quick Google search of "determine linux distro" shows, there 
is NO standard way to determine it!  The description of the Python 
distro package at https://pypi.org/project/distro/ describes 4 different 
places one must look in order to get that information.  And, I'd guess 
that even that might not cover all the possible distros out there.  Sigh!


On 2/16/2019 2:40 PM, Chip Davis wrote:
I'm sure I'm not the only one on this list old enough to remember the 
sage observation of Prof. Tanenbaum, "The nice thing about standards 
is that you have so many to choose from."


-Chip-

 Original message 
From: Jason Martin 
Date: 2/16/19 13:50 (GMT-05:00)
To: Enrico Sorichetti via Oorexx-devel 


Subject: Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

I know, knew, just saying even standards are not standard.



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


--
Gil Barmwater

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

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Enrico Sorichetti via Oorexx-devel 
The problem is that there is no automatic way to find out to such detail

Just run … 
 cmake --system-information [file]  = Dump information about this system.
To see what cmake can find out about Your system

E

> On 16 Feb 2019, at 21:07, Gil Barmwater  wrote:
> 
>  I was just suggesting that if we know how to name that file for the platform 
> for which it is intended, 

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

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Gil Barmwater 
Let me try again.  When a user wants to install ooRexx on his platform, 
he goes to SF and looks in the Files section under the ooRexx tab for 
the most recent file with a name that matches his platform, downloads it 
and uses the appropriate installation mechanism for that platform.  I 
was just suggesting that if we know how to name that file for the 
platform for which it is intended, we might make the executable be able 
to also know (and supply) that information.  The programmer/testcase 
writer could then tailor his program to behave appropriately for that 
platform if necessary.  FWIW


On 2/16/2019 2:53 PM, Enrico Sorichetti via Oorexx-devel wrote:

something built on a certain a platform  WILL NOT run on a different one

LINUX will be even more selective
There are subtle differences between the different distributions

And there are also common practices to deal with …

 xx.deb is likely a package for Debian family system

 x.rpm is the same for red hat family systems

The package type is usually a good hint on the distribution it might 
run on

E







On 16 Feb 2019, at 20:37, Rick McGuire > wrote:


That’s only the platform it was built on, not necessarily the one 
it’s running on.




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


--
Gil Barmwater

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

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Enrico Sorichetti via Oorexx-devel 
Funny … after setting a missing CPACK variable

Before

ooRexx-5.0.0-11767.x86_64.deb

The name had a reference to the svn revision

After

ooRexx-5.0.0-Linux.deb

Nothing

Weird ???

E

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

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Enrico Sorichetti via Oorexx-devel 
something built on a certain a platform  WILL NOT run on a different one

LINUX will be even more selective 
There are subtle differences between the different distributions 

And there are also common practices to deal with …

 xx.deb is likely a package for Debian family system 

 x.rpm is the same for red hat family systems 

The package type is usually a good hint on the distribution it might run on
 
E

 






> On 16 Feb 2019, at 20:37, Rick McGuire  wrote:
> 
> That’s only the platform it was built on, not necessarily the one it’s 
> running on.

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

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Rick McGuire 
That’s only the platform it was built on, not necessarily the one it’s
running on.

On Sat, Feb 16, 2019 at 2:14 PM Gil Barmwater 
wrote:

> OK, so CMAKE "knows" the PLATFORM_ID which, I'm guessing, is used to
> generate the name of the ooRexx installation file; e.g.
> ooRexx-5.0.0-11742.centos7.x86_64.rpm
> .
> Would it make sense for CMAKE to pass that data to the build where it could
> be retrieved by a new attribute such as .rexxinfo~distro?
> On 2/16/2019 1:17 PM, Enrico Sorichetti via Oorexx-devel wrote:
>
> Cmake  should return “sunOS”
>
> From the compiler builtin macro
>
> #elif defined(__sun) || defined(sun)
> # define PLATFORM_ID "SunOS"
>
>
>
> On 16 Feb 2019, at 18:40, Jason Martin  
>  wrote:
>
> agrellum@openindiana:~$ uname -v
> illumos-c78b1a4529
>
> Not OpenIndiana and Not SunOS
>
>
>
>
> ___
> Oorexx-devel mailing 
> listOorexx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> ___
> Oorexx-devel mailing 
> listOorexx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
> --
> Gil Barmwater
>
> ___
> 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] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Enrico Sorichetti via Oorexx-devel 
I guess not …
From my tests they create something
.


ooRexx-5.0.0-Linux.sh
ooRexx-5.0.0-Linux.tar.Z
ooRexx-5.0.0-Linux.tar.gz

I did it on Fedora but the result is exactly the same for Debian 

For the other tests I run 
I got the same layout with Darwin, FreeBSD, OpenBSD, instead of Linux

Just tested one debian 
Pack -G DEB

I got some errors but the name of the deb was

ooRexx-5.0.0-11767.x86_64.deb

No reference to the linux distro name

E

> On 16 Feb 2019, at 19:42, Gil Barmwater  wrote:
> 
> OK, so CMAKE "knows" the PLATFORM_ID which, I'm guessing, is used to generate 
> the name of the ooRexx installation file; e.g. 
> ooRexx-5.0.0-11742.centos7.x86_64.rpm 
> .
>   Would it make sense for CMAKE to pass that data to the build where it could 
> be retrieved by a new attribute such as .rexxinfo~distro?
> 
> On 2/16/2019 1:17 PM, Enrico Sorichetti via Oorexx-devel wrote:
>> Cmake  should return “sunOS”
>> 
>> From the compiler builtin macro 
>> 
>> #elif defined(__sun) || defined(sun)
>> # define PLATFORM_ID "SunOS"
>> 
>> 
>>> On 16 Feb 2019, at 18:40, Jason Martin  
>>>  wrote:
>>> 
>>> agrellum@openindiana:~$ uname -v
>>> illumos-c78b1a4529
>>> 
>>> Not OpenIndiana and Not SunOS
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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 
>> 
> -- 
> Gil Barmwater
> ___
> 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] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Gil Barmwater 
OK, so CMAKE "knows" the PLATFORM_ID which, I'm guessing, is used to 
generate the name of the ooRexx installation file; e.g. 
ooRexx-5.0.0-11742.centos7.x86_64.rpm 
. 
Would it make sense for CMAKE to pass that data to the build where it 
could be retrieved by a new attribute such as .rexxinfo~distro?


On 2/16/2019 1:17 PM, Enrico Sorichetti via Oorexx-devel wrote:

Cmake  should return “sunOS”

 From the compiler builtin macro

#elif defined(__sun) || defined(sun)
# define PLATFORM_ID "SunOS"



On 16 Feb 2019, at 18:40, Jason Martin  wrote:

agrellum@openindiana:~$ uname -v
illumos-c78b1a4529

Not OpenIndiana and Not SunOS




___
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


--
Gil Barmwater

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

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Jason Martin 

I know, knew, just saying even standards are not standard.




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

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Enrico Sorichetti via Oorexx-devel 
Cmake  should return “sunOS”

From the compiler builtin macro 

#elif defined(__sun) || defined(sun)
# define PLATFORM_ID "SunOS"


> On 16 Feb 2019, at 18:40, Jason Martin  wrote:
> 
> agrellum@openindiana:~$ uname -v
> illumos-c78b1a4529
> 
> Not OpenIndiana and Not SunOS
> 
> 
> 
> 
> ___
> 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] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Jason Martin 

agrellum@openindiana:~$ uname -v
illumos-c78b1a4529

Not OpenIndiana and Not SunOS




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

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Enrico Sorichetti via Oorexx-devel 

> Should maybe "PARSE SOURCE" return "UBUNTU" instead of "LINUX" to indicate 
> that it behaves
> differently compared to other Linuxes?


Parse source return the info provides by CMAKE_SYSTEM_NAME
And by some tweak of configure.ac before that

I just run a
cmake --system-information info.txt

But nothing useful there


The only command that might give a hint about the linux distribution might be
Some variant of the uname command and the equivalent programmatic construct 


[vagrant@debian9 ~]$uname -v
#1 SMP Debian 4.9.144-3 (2019-02-02)


But …

[vagrant@fedora ~]$uname -v
#1 SMP Wed Feb 13 13:08:05 UTC 2019

And

[enrico@imac ~]$uname -v
Darwin Kernel Version 17.7.0: Thu Dec 20 21:47:19 PST 2018; 
root:xnu-4570.71.22~1/RELEASE_X86_64


Unfortunately it is also almost impossible to parse the information returned by 
the 
 command uname -a 


If it is possible to determine the testing path with the info we have now 
 without too many IFs or CASEs lets keep it that way

For borderline cases like this one I would make a group of 
 ?questionable test cases with odd behaviour without the assertions
 but with a short explication of the different results

Have a nice weekend 

Cheers

E




> On 16 Feb 2019, at 16:41, Rony G. Flatscher  wrote:
> 
> What would you suggest/advise given your huge knowledge and experiences on so 
> many different Unix
> systems?
> 
> Should the test be adapted to check whether Ubuntu is the host system (e.g. 
> "if
> sysVersion()~caselessPos('Ubuntu')>0 then ...")?
> 
> Should the function work differently on Ubuntu to match the behaviour of 
> other Unix systems? If so,
> how could one determine/decide which behaviour should be expected/picked by 
> Rexx programmers
> employing them?
> 
> Should the functions behave according to the host system's behaviour, but 
> document it? If so, then
> maybe a means for querying the exact behaviour might become important for 
> Rexx programmers to adjust
> their logic accordingly (or pick a different function or use address).
> 
> How should differences among Unix versions be handled in principle?
> 
> Should maybe "PARSE SOURCE" return "UBUNTU" instead of "LINUX" to indicate 
> that it behaves
> differently compared to other Linuxes?
> 
> ---rony
> 
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Rony G. Flatscher 
What would you suggest/advise given your huge knowledge and experiences on so 
many different Unix
systems?

Should the test be adapted to check whether Ubuntu is the host system (e.g. "if
sysVersion()~caselessPos('Ubuntu')>0 then ...")?

Should the function work differently on Ubuntu to match the behaviour of other 
Unix systems? If so,
how could one determine/decide which behaviour should be expected/picked by 
Rexx programmers
employing them?

Should the functions behave according to the host system's behaviour, but 
document it? If so, then
maybe a means for querying the exact behaviour might become important for Rexx 
programmers to adjust
their logic accordingly (or pick a different function or use address).

How should differences among Unix versions be handled in principle?

Should maybe "PARSE SOURCE" return "UBUNTU" instead of "LINUX" to indicate that 
it behaves
differently compared to other Linuxes?

---rony



On 16.02.2019 15:53, Enrico Sorichetti via Oorexx-devel wrote:
> I started a bit earlier ( do You remember Slackware )
>
> After that I went for Red Hat
>
> And got used to the red-hat and friends terminology 
>
> I can agree on the Debian ways 
> But Ubuntu has taken things a bit too far
>
> Apart being too much much windowish for my taste ;-)
>
> This morning it took me  just 40 minutes to setup a Debian working 
> environment for ooRexx
> I tried last week with ubuntu and I stopped trying after one day 
>
> And … a couple of years ago developing with ubuntu
> Was really painful for the very bad choice they had made for the compiler and 
> the headers 
> Many configure.ac checks  had to be rewritten  because of that 
> ( I got burned by the atomic support detection )
>
>
> Cheers
> E
>
>> On 16 Feb 2019, at 15:31, Michael Lueck  wrote:
>>
>> Enrico Sorichetti via Oorexx-devel wrote:
>>> Unfortunately Ubuntu is well known also for its odd way of doing things
>>
>> haha...
>>
>> The Debian / Ubuntu way makes sense, the other distros are the odd ones! ;-)
>>
>> Seriously... I started out with Red Hat 5.2 back in probably 1999. Yuck. 
>> SuSE, Mandrake... more yuck.
>>
>> Then in 2004 my "right hand man in America" suggested I try Debian... which 
>> I had heard had a reputation of being "stick shift'ish"... and quickly 
>> connected with it.
>>
>> One of the big draws for me was that dpkg came with built-in package 
>> dependency checking whereas rpm lacked it.
>>
>> 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] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Enrico Sorichetti via Oorexx-devel 
I started a bit earlier ( do You remember Slackware )

After that I went for Red Hat

And got used to the red-hat and friends terminology 

I can agree on the Debian ways 
But Ubuntu has taken things a bit too far

Apart being too much much windowish for my taste ;-)

This morning it took me  just 40 minutes to setup a Debian working environment 
for ooRexx
I tried last week with ubuntu and I stopped trying after one day 

And … a couple of years ago developing with ubuntu
Was really painful for the very bad choice they had made for the compiler and 
the headers 
Many configure.ac checks  had to be rewritten  because of that 
( I got burned by the atomic support detection )


Cheers
E

> On 16 Feb 2019, at 15:31, Michael Lueck  wrote:
> 
> Enrico Sorichetti via Oorexx-devel wrote:
>> Unfortunately Ubuntu is well known also for its odd way of doing things
> 
> 
> haha...
> 
> The Debian / Ubuntu way makes sense, the other distros are the odd ones! ;-)
> 
> Seriously... I started out with Red Hat 5.2 back in probably 1999. Yuck. 
> SuSE, Mandrake... more yuck.
> 
> Then in 2004 my "right hand man in America" suggested I try Debian... which I 
> had heard had a reputation of being "stick shift'ish"... and quickly 
> connected with it.
> 
> One of the big draws for me was that dpkg came with built-in package 
> dependency checking whereas rpm lacked it.
> 
> 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



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

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Michael Lueck 

Enrico Sorichetti via Oorexx-devel wrote:

Unfortunately Ubuntu is well known also for its odd way of doing things



haha...

The Debian / Ubuntu way makes sense, the other distros are the odd ones! ;-)

Seriously... I started out with Red Hat 5.2 back in probably 1999. Yuck. SuSE, 
Mandrake... more yuck.

Then in 2004 my "right hand man in America" suggested I try Debian... which I had heard 
had a reputation of being "stick shift'ish"... and quickly connected with it.

One of the big draws for me was that dpkg came with built-in package dependency 
checking whereas rpm lacked it.

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] Testing Open Object Rexx Version 5.0.0 r11766 and testsuite at r11767

2019-02-16 Thread Enrico Sorichetti via Oorexx-devel 

You should be more open minded and 
Spend more time to learn about the different Linux distributions behaviour 

I spent a couple of hours installing one more Linux distribution 
I choose Debian, much more trustworthy as a high lever developer platform …

And guess what ???

Executing /home/vagrant/ooRexx.testSuite/.../base/rexxutil/SysFileXXX.testGroup

ooTest Framework - Automated Test of the ooRexx Interpreter

Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 16 Feb 2019
OS Name:LINUX
SysVersion: Linux 4.9.0-8-amd64

Tests ran:  9
Assertions: 91
Failures:   1
Errors: 0

[failure] [20190216 05:33:12.477272]
  svn:r11734   Change date: 2019-02-08 15:41:41 -0500
  Test:   TEST_FILE_EXISTS
  Class:  SysFileXXX.testgroup
  File:   /home/vagrant/ooRexx.testSuite/.../base/rexxutil/SysFileXXX.testGroup
  Line:   118
  Failed: assertNotEquals
Expected: [[0], identityHash="-140654221754385"]
Actual:   [[0], identityHash="-140654221754385"]

File search:00:00:00.031671
Suite construction: 00:00:00.000714
Test execution: 00:00:00.011347
Total time: 00:00:00.515426


I do not question Your competence about the internal of ooRexx 

But You should learn to trust the judgement of other people
with a bit more experience and knowledge about system infrastructure


And … YES I run the test on  the testSuite 
AtLast Changed Rev: 11767

So Your last mod was just useless attempt to show that You were right 

But unfortunately You miserably failed

My best regards

Dr. Enrico Sorichetti



> On 16 Feb 2019, at 13:09, Enrico Sorichetti  wrote:
> 
> Unfortunately Ubuntu is well known also for its odd way of doing things
> 
> 
> 
>> On 16 Feb 2019, at 12:55, Rick McGuire > > wrote:
>> 
>> It is Unbuntu's though. 
> 

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

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Enrico Sorichetti via Oorexx-devel 
Unfortunately Ubuntu is well known also for its odd way of doing things



> On 16 Feb 2019, at 12:55, Rick McGuire  wrote:
> 
> It is Unbuntu's though. 

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

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Rick McGuire 
It is Unbuntu's though.

Rick

On Sat, Feb 16, 2019 at 6:54 AM Enrico Sorichetti via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:

> Well… that’ not Fedora Linux opinion
>
>
> Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 16 Feb 2019
> OS Name:LINUX
> SysVersion: Linux 4.20.7-200.fc29.x86_64
>
> Tests ran:  22641
> Assertions: 377418
> Failures:   1
> Errors: 0
>
> [failure] [20190216 11:27:47.784343]
>   svn:r11734   Change date: 2019-02-08 15:41:41 -0500
>   Test:   TEST_FILE_EXISTS
>   Class:  SysFileXXX.testgroup
>   File:   /home/vagrant/testSuite/ooRexx/base/rexxutil/SysFileXXX.testGroup
>   Line:   116
>   Failed: assertNotEquals
> Expected: [[0], identityHash="-140136418406417"]
> Actual:   [[0], identityHash="-140136418406417"]
>
>
>
> On 16 Feb 2019, at 12:48, Rick McGuire  wrote:
>
> It's not so simple. That test works as expected on Linux, it looks like it
> is only failing on Darwin.
>
>
> ___
> 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] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Enrico Sorichetti via Oorexx-devel 
Well… that’ not Fedora Linux opinion 


Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 16 Feb 2019
OS Name:LINUX
SysVersion: Linux 4.20.7-200.fc29.x86_64

Tests ran:  22641
Assertions: 377418
Failures:   1
Errors: 0

[failure] [20190216 11:27:47.784343]
  svn:r11734   Change date: 2019-02-08 15:41:41 -0500
  Test:   TEST_FILE_EXISTS
  Class:  SysFileXXX.testgroup
  File:   /home/vagrant/testSuite/ooRexx/base/rexxutil/SysFileXXX.testGroup
  Line:   116
  Failed: assertNotEquals
Expected: [[0], identityHash="-140136418406417"]
Actual:   [[0], identityHash="-140136418406417"]



> On 16 Feb 2019, at 12:48, Rick McGuire  wrote:
> 
> It's not so simple. That test works as expected on Linux, it looks like it is 
> only failing on Darwin. 

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

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Rick McGuire 
It's not so simple. That test works as expected on Linux, it looks like it
is only failing on Darwin.

Rick

On Sat, Feb 16, 2019 at 6:38 AM Enrico Sorichetti via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:

> Certainly different from windows ,
>
> On unix it behaves according to the docs
>
> deleteFile uses unlink which does not check the permissions on the file
>
> E
>
> Quoting the libc manual
>
>
> 14.6 Deleting Files
>
> You can delete a file with unlink or remove.
>
> Deletion actually deletes a file name. If this is the file’s only name,
> then the file is deleted as well. If the file has other remaining names
> (see Hard Links
> ),
> it remains accessible under those names.
> Function: *int* *unlink* *(const char *filename)*
>
> Preliminary: | MT-Safe | AS-Safe | AC-Safe | See POSIX Safety Concepts
> 
> .
>
> The unlink function deletes the file name filename. If this is a file’s
> sole name, the file itself is also deleted. (Actually, if any process has
> the file open when this happens, deletion is postponed until all processes
> have closed the file.)
>
> The function unlink is declared in the header file unistd.h.
>
> This function returns 0 on successful completion, and -1 on error. In
> addition to the usual file name errors (see File Name Errors
> ),
> the following errno error conditions are defined for this function:
> EACCES
>
> Write permission is denied for the directory from which the file is to be
> removed, or the directory has the sticky bit set and you do not own the
> file.
> EBUSY
>
> This error indicates that the file is being used by the system in such a
> way that it can’t be unlinked. For example, you might see this error if the
> file name specifies the root directory or a mount point for a file system.
> ENOENT
>
> The file name to be deleted doesn’t exist.
> EPERM
>
> On some systems unlink cannot be used to delete the name of a directory,
> or at least can only be used this way by a privileged user. To avoid such
> problems, use rmdir to delete directories. (On GNU/Linux and GNU/Hurd
> systems unlink can never delete the name of a directory.)
> EROFS
>
> The directory containing the file name to be deleted is on a read-only
> file system and can’t be modified.
>
> 11.2.3 File Name Errors
>
> Functions that accept file name arguments usually detect these errno error
> conditions relating to the file name syntax or trouble finding the named
> file. These errors are referred to throughout this manual as the *usual
> file name errors*.
> EACCES
>
> The process does not have search permission for a directory component of
> the file name.
> ENAMETOOLONG
>
> This error is used when either the total length of a file name is greater
> than PATH_MAX, or when an individual file name component has a length
> greater than NAME_MAX. See Limits for Files
> 
> .
>
> On GNU/Hurd systems, there is no imposed limit on overall file name
> length, but some file systems may place limits on the length of a component.
> ENOENT
>
> This error is reported when a file referenced as a directory component in
> the file name doesn’t exist, or when a component is a symbolic link whose
> target file does not exist. See Symbolic Links
> 
> .
> ENOTDIR
>
> A file that is referenced as a directory component in the file name
> exists, but it isn’t a directory.
> ELOOP
>
> Too many symbolic links were resolved while trying to look up the file
> name. The system has an arbitrary limit on the number of symbolic links
> that may be resolved in looking up a single file name, as a primitive way
> to detect loops. See Symbolic Links
> 
> .
>
>
>
>
> On 16 Feb 2019, at 11:44, Rick McGuire  wrote:
>
> No, those are correct. The test is expecting that an attempt to delete a
> read-only file will fail. Just another one of those maddening differences
> between platforms.
>
>
> ___
> 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] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Enrico Sorichetti via Oorexx-devel 
Certainly different from windows , 

On unix it behaves according to the docs

deleteFile uses unlink which does not check the permissions on the file

E

Quoting the libc manual


14.6 Deleting Files

 <> <> <>You can delete a file with unlink or remove.

Deletion actually deletes a file name. If this is the file’s only name, then 
the file is deleted as well. If the file has other remaining names (see Hard 
Links 
),
 it remains accessible under those names.

 <>Function: int unlink (const char *filename)
Preliminary: | MT-Safe | AS-Safe | AC-Safe | See POSIX Safety Concepts 
.

The unlink function deletes the file name filename. If this is a file’s sole 
name, the file itself is also deleted. (Actually, if any process has the file 
open when this happens, deletion is postponed until all processes have closed 
the file.)

 <>The function unlink is declared in the header file unistd.h.

This function returns 0 on successful completion, and -1 on error. In addition 
to the usual file name errors (see File Name Errors 
),
 the following errno error conditions are defined for this function:

EACCES
Write permission is denied for the directory from which the file is to be 
removed, or the directory has the sticky bit set and you do not own the file.

EBUSY
This error indicates that the file is being used by the system in such a way 
that it can’t be unlinked. For example, you might see this error if the file 
name specifies the root directory or a mount point for a file system.

ENOENT
The file name to be deleted doesn’t exist.

EPERM
On some systems unlink cannot be used to delete the name of a directory, or at 
least can only be used this way by a privileged user. To avoid such problems, 
use rmdir to delete directories. (On GNU/Linux and GNU/Hurd systems unlink can 
never delete the name of a directory.)

EROFS
The directory containing the file name to be deleted is on a read-only file 
system and can’t be modified.


11.2.3 File Name Errors

 <> <>Functions that accept file name arguments usually detect these errno 
error conditions relating to the file name syntax or trouble finding the named 
file. These errors are referred to throughout this manual as the usual file 
name errors.

EACCES
The process does not have search permission for a directory component of the 
file name.

ENAMETOOLONG
This error is used when either the total length of a file name is greater than 
PATH_MAX, or when an individual file name component has a length greater than 
NAME_MAX. See Limits for Files 
.

On GNU/Hurd systems, there is no imposed limit on overall file name length, but 
some file systems may place limits on the length of a component.

ENOENT
This error is reported when a file referenced as a directory component in the 
file name doesn’t exist, or when a component is a symbolic link whose target 
file does not exist. See Symbolic Links 
.

ENOTDIR
A file that is referenced as a directory component in the file name exists, but 
it isn’t a directory.

ELOOP
Too many symbolic links were resolved while trying to look up the file name. 
The system has an arbitrary limit on the number of symbolic links that may be 
resolved in looking up a single file name, as a primitive way to detect loops. 
See Symbolic Links 
.





> On 16 Feb 2019, at 11:44, Rick McGuire  wrote:
> 
> No, those are correct. The test is expecting that an attempt to delete a 
> read-only file will fail. Just another one of those maddening differences 
> between platforms. 

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

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Rick McGuire 
No, those are correct. The test is expecting that an attempt to delete a
read-only file will fail. Just another one of those maddening differences
between platforms.

Rick

On Sat, Feb 16, 2019 at 4:02 AM Enrico Sorichetti via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:

>
> Seems to work,
>
> But It looks like
>
> [failure] [20190216 09:49:03.638306]
>   svn:r11734   Change date: 2019-02-08 15:41:41 -0500
>   Test:   TEST_FILE_EXISTS
>   Class:  SysFileXXX.testgroup
>   File:
> /Users/enrico/ooRexx.testSuite/.../base/rexxutil/SysFileXXX.testGroup
>   Line:   116
>   Failed: assertNotEquals
> Expected: [[0], identityHash="-4422832129"]
> Actual:   [[0], identityHash="-4422832129"]
>
>
> And
>
> [failure] [20190216 09:51:18.680336]
>   svn:r11734   Change date: 2019-02-08 15:41:41 -0500
>   Test:   TEST_FILE_EXISTS
>   Class:  SysFileXXX.testgroup
>   File:
> /Users/enrico/ooRexx.testSuite/.../base/rexxutil/SysFileXXX.testGroup
>   Line:   118
>   Failed: assertEquals
> Expected: [[0], identityHash="-4374581249"]
> Actual:   [[2], identityHash="-4374659313"]
>
>
>
> Should be reversed
>
> E
>
> PS.
>
> The first one certainly,
> I am not sure about the second
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Enrico Sorichetti via Oorexx-devel 

Seems to work,

But It looks like 

[failure] [20190216 09:49:03.638306]
  svn:r11734   Change date: 2019-02-08 15:41:41 -0500
  Test:   TEST_FILE_EXISTS
  Class:  SysFileXXX.testgroup
  File:   /Users/enrico/ooRexx.testSuite/.../base/rexxutil/SysFileXXX.testGroup
  Line:   116
  Failed: assertNotEquals
Expected: [[0], identityHash="-4422832129"]
Actual:   [[0], identityHash="-4422832129"]


And 

[failure] [20190216 09:51:18.680336]
  svn:r11734   Change date: 2019-02-08 15:41:41 -0500
  Test:   TEST_FILE_EXISTS
  Class:  SysFileXXX.testgroup
  File:   /Users/enrico/ooRexx.testSuite/.../base/rexxutil/SysFileXXX.testGroup
  Line:   118
  Failed: assertEquals
Expected: [[0], identityHash="-4374581249"]
Actual:   [[2], identityHash="-4374659313"]



Should be reversed

E

PS.

The first one certainly,
I am not sure about the second 





























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