Make case sensitivity user settable

[kenneth-olwing]

The construction of a static decision to treat everything as case sensitive
or not is an assumption that doesn't always hold. Keep the current
behavior, but make it possible for the caller to explicitly set
case sensitivity.

In my use case I do '$obj->survey($dir1, $dir2)', where there are in fact a 'wlstab.pod' in dir1 (being a file format description) and a 'Wlstab.pm' in dir2 (being a module to deal with that format). This fails on Windows on a filesystem that is case insensitive, but the assumption to discard the second file
during the survey is incorrect in this case. Hence, I need a way to ensure this doesn't happen.
This behavior is needed in my App::Pods2Site application.

[khwilliamson]

Could you also submit a few lines to document this in Search.pm pod

[karenetheridge]

FYI -- you can make use of the case_tolerant function in File::Spec to inquire whether your particular filesystem should do non-case-sensitive string comparisons or not. Some architecture implmentations of this function actually probe the filesystem to make this determination, rather than hardcoding a true or false value.

[kenneth-olwing]

Could you also submit a few lines to document this in Search.pm pod

Doh - yes of course. Totally forgot about that. Done.

[kenneth-olwing]

FYI -- you can make use of the case_tolerant function in File::Spec to inquire whether your particular filesystem should do non-case-sensitive string comparisons or not. Some architecture implmentations of this function actually probe the filesystem to make this determination, rather than hardcoding a true or false value.

Well, that's true, but as usual, things are more complex than that.

First, I should mention that I wanted to keep the behavior as-is, obviously, so I just re-used the same method that had been used before...

===

...rant on...

...which is full-blown bogus of course anyway in so many ways it's hard to count...even on a case-sensitive filesystem there's nothing stopping me from having both x.pm and X.PM, but this would lead to an assumption that we're case insensitive. Also, where the module is installed has nothing to do where it's going to search. And so on...

And I submit that File::Spec->case_tolerant() is mostly bogus too, also for a number of reasons. For example, what does 'case tolerant' mean in comparison to 'case insensitive'? The normal filesystem on a Windows box is NTFS. It normally is case insensitive, but it is also case preserving which is important. What does 'case tolerant' even mean, given that (I'd claim that yes, it's case tolerant, but it's probably not what was intended)? Further, there are other file systems for Windows, some of which are/can be fully case sensitive.

And yes, it mentions that for Cygwin/Windows it takes a drive letter, presumably to probe them. What happens if it's read-only? And if I use UNC paths directly rather than mounting them to drive letters (i.e. \server\share...)? And the use of drive letters is enormously archaic - for the past 15-20 years I've routinely mounted my hard disks beyond the boot one using volume mount points in C:\dev rather than using drive letter, and admittedly, while not common, they each can have different file systems, some of which may indeed be case sensitive even if C: is not. Add junction points and symlinks and the possibilities get even bigger. A bit beyond is also the fact that NTFS handles Unicode...with names beyond ascii, lc/uc sort of gets very different.

In reverse, what happens in a Linux box that mounts an NTFS volume? Haven't tried, but it must routinely treat that as case insensitive, no?

...rant off...

Sorry, it's just a jungle out there... :-)

[kenneth-olwing]

I found a small problem when running tests on Windows, maybe that should have been in a different PR but...

Also, while the check fails, it appears to be something broken on the travis side, it can't unpack a 5.8 file. I can't see it related to this PR at any rate.

Finally, just curious on how the typical process is for how/when the PR is merged and when it will appear on CPAN? Maybe you're waiting for other fixes or it's only once a month or whenever time is available...well, just'd like to have an understanding so I can plan for making the upgrade to my module that needs this fix.

Thanks for your help

[khwilliamson]

On 9/19/19 10:03 AM, Kenneth Ölwing wrote: I found a small problem when running tests on Windows, maybe that should have been in a different PR but... Also, while the check fails, it appears to be something broken on the travis side, it can't unpack a 5.8 file. I can't see it related to this PR at any rate. Finally, just curious on how the typical process is for how/when the PR is merged and when it will appear on CPAN? Maybe you're waiting for other fixes or it's only once a month or whenever time is available...well, just'd like to have an understanding so I can plan for making the upgrade to my module that needs this fix. Thanks for your help

It all depends. I can make a release soon if you need it. There were some other things I'm looking into, but they can wait.

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#111?email_source=notifications&email_token=AAA2DHYSTPDNTQELNWA4S6TQKOPG7A5CNFSM4IWJIA72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7D7WBQ#issuecomment-533199622>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAA2DH3TS2X6XQ3KAH6LOLTQKOPG7ANCNFSM4IWJIA7Q>.

[kenneth-olwing]

It all depends. I can make a release soon if you need it. There were some other things I'm looking into, but they can wait.

Awesome - no critical hurry, but if it's possible sometime next week or two it'd help.

Thanks!