Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-26 Thread Rick McGuire
I had thought of using the attrs, but it seems a bit of a kludge to only support the one flag, but still requires the others to fix what really feels like an out-right bug to me. Rick On Sat, Jan 26, 2019 at 7:17 AM Erich Steinböck wrote: > try this out with a private build >> There are four

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-26 Thread Erich Steinböck
> > try this out with a private build > There are four places where the FMN_PERIOD option is used. > Just remove that flag, which will change the behavior > With FNM_PERIOD removed from the current trunk code, SysFileTree will find all files in my test scenario ~~~ ~/sysfiletree$ rexx -e "call

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-26 Thread Rick McGuire
The code isn't close to building yet. Working my way through the compile error still. Thanks for catching a few! Rick On Sat, Jan 26, 2019 at 5:48 AM Erich Steinböck wrote: > try this out with a private build > > Rick, can you please check in ExternalFileBuffer.hpp ? This seems missing > from

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-26 Thread Erich Steinböck
> > try this out with a private build Rick, can you please check in ExternalFileBuffer.hpp ? This seems missing from sandbox/rick/rexxutil Also these patches will probably be required to build: ~~~ === --- CMakeLists.txt

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-25 Thread Michael Lueck
Greetings ooRexx'ers, Jeremy Nicoll wrote: On Fri, 25 Jan 2019, at 16:54, Rick McGuire wrote: Ok, I found out the cause of the behavior with leading dots BRAVO! Excellent sleuthing!!! I think it should be possible to get all matching filenames with a single call of SysFileTree,

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-25 Thread Jeremy Nicoll
On Fri, 25 Jan 2019, at 16:54, Rick McGuire wrote: > Ok, I found out the cause of the behavior with leading dots I think it should be possible to get all matching filenames with a single call of SysFileTree, and for recursion into hidden dirs to be supported. If you think that changing the

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-25 Thread Rick McGuire
Ok, I found out the cause of the behavior with leading dots. The unix version of rexxutil uses the fnmatch() function for matching filenames that might include "globbing". One of the options it is using is FMN_PERIOD, which does not allow a leading period to be be matched by a wildcard character.

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-25 Thread Michael Lueck
Greetings ooRexx'ers, Erich Steinböck wrote: As far as I can see, the issue is a) you cannot list hidden (leading dot) and normal files in one call and b) SysFileTree won't recurse into a hidden directory Here is a test scenario: Yes Erich, that is succinctly the issue comparing native

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-25 Thread Erich Steinböck
> > #864 SysFileTree under win32 > matches on long & short file name > I'm not sure I really like adding an option here that only has meaning for Windows...I'm trying to minimize the amount of platform-specific code used here. I'd really prefer to just

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-25 Thread Rick McGuire
On Sat, Jan 19, 2019 at 6:05 AM Erich Steinböck wrote: > I'm using "Z" for now, unless there's a better suggestion. >> > According to the discussion in the open bug report #1318 > SysFileTree wrong for files > > 4096 MB the flag should be H for Huge,

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-19 Thread Rick McGuire
Ok, H sounds fine to me. I'll take a look at the rest of the bugs/features to see if I can fix them. Rick On Sat, Jan 19, 2019 at 6:05 AM Erich Steinböck wrote: > I'm using "Z" for now, unless there's a better suggestion. >> > According to the discussion in the open bug report #1318 >

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-19 Thread Erich Steinböck
> > I'm using "Z" for now, unless there's a better suggestion. > According to the discussion in the open bug report #1318 SysFileTree wrong for files > 4096 MB the flag should be H for Huge, consistent with Regina (whose docs say "If it includes ‘h’

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-18 Thread Enrico Sorichetti via Oorexx-devel
Sorry for the typo, I meant Both case sensitive and case INsensitive file systems E > On 19 Jan 2019, at 00:37, Enrico Sorichetti wrote: > > APPLE supports both case sensitive and case sensitive filesystems > ___ Oorexx-devel mailing list

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-18 Thread Enrico Sorichetti via Oorexx-devel
APPLE supports both case sensitive and case sensitive filesystems And since _PC_CASE_SENSITIVE is defined and pathconf works No reason at all to use a default. For the sake of logical consistency You might want to add to theCMakelists the function_exists test The testSuite MUST be fixed, it

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-18 Thread Michael Lueck
Greetings Rick, Rick McGuire wrote: Doing some rework on SysFileTree to clean it up Much thanks! First, the question of long file names. Unfortunately, because people might be using positional parsing on the returned string, just unilaterally increasing the size doesn't really work. It's

[Oorexx-devel] A couple of discussion questions about SysFileTree

2019-01-18 Thread Rick McGuire
Doing some rework on SysFileTree to clean it up and reduce the amount of platform-specific code. There are a couple of changes I think need to be made. First, the question of long file names. Unfortunately, because people might be using positional parsing on the returned string, just unilaterally