libcurl on Windows boxes ?

Hello,

I'm trying to use libcurl with Perl on a Windows box. I try with PPM,
but it didn't find the WWW::Curl module. On the website
http://curl.haxx.se/libcurl/perl/ we can download to compile from
source, but it looks like it's working only on Unixes.

Does someone has already achieve to make libcurl work on Windows with
Perl ? I didn't want to recompile everything (well except if it's the
only way, but I don't have any Visual-xxx).

Thanks for your help,

NB : I've search in the newsgroups archives and didn't find anything,
as well as with Google

Re: libcurl on Windows boxes ?

On Sat, 1 Jul 2006 19:52:40 +1000, tomazi75@gmail.com wrote:

Hi

> source, but it looks like it's working only on Unixes.

Rubbish! http://curl.haxx.se/download.html#Win32

Re: libcurl on Windows boxes ?

> > source, but it looks like it's working only on Unixes.
>
> Rubbish! http://curl.haxx.se/download.html#Win32

I meaned "it looks like *libcurl for Perl* is working only on Unixes".
I've install Cygwin and recompiled everything. It works fine now (but
needs Cygwin).

Re: libcurl on Windows boxes ?

wrote in message
news:1151842187.256745.184990@a14g2000cwb.googlegroups.com.. .
> > > source, but it looks like it's working only on Unixes.
> >
> > Rubbish! http://curl.haxx.se/download.html#Win32
>
> I meaned "it looks like *libcurl for Perl* is working only on Unixes".
> I've install Cygwin and recompiled everything. It works fine now (but
> needs Cygwin).
>

Looking at the page that Ron posted a link to, I see there are downloads for
"Win32 - Generic", "Win32 - cygwin", and "Win32 - MSVC".

Having downloaded
http://curl.haxx.se/download/libcurl-7.15.4-win32-nossl.zip from the
"Win32 - Generic" section, it looks to me that this will work with the MinGW
compiler (native Win32 port of gcc compiler).

I didn't download anything from the "Win32 -cygwin" section as I suspect
it's for Cygwin only .... and I'm not all that interested in Cygwin.

Having downoaded http://curl.haxx.se/download/libcurl-7.15.2-win32-msvc.zip
from the "Win32 - MSVC" section, it looks to me that this will work on
(native) Win32 with Microsoft compilers.

What specific problem were you having in getting libcurl to work with native
(as opposed to Cygwin) Win32 ?

Aaah ... but hang on ..... are you saying the problem is with WWW::Curl ?
It's quite likely that *won't* build "straight out of the box", so to
speak - but some simple hacks at the Makefile.PL should fix that problem.
What specific problem were you having getting WWW::Curl to build ?

If you just want a ppm run (for perl 5.8):
ppm install http://theoryx5.uwinnipeg.ca/ppms/WWW-Curl.ppd

If you're running perl 5.6:
ppm install http://theoryx5.uwinnipeg.ca/ppmpackages/WWW-Curl.ppd

(That will give you version 3.02 of WWW-Curl.)

For a listing of other packages available there, browse to:
http://theoryx5.uwinnipeg.ca/ppms/ (for perl 5.8 packages)
http://theoryx5.uwinnipeg.ca/ppmpackages/ (for perl 5.6 packages)

Cheers,
Rob

Re: libcurl on Windows boxes ?

> Looking at the page that Ron posted a link to, I see there are downloads for
> "Win32 - Generic", "Win32 - cygwin", and "Win32 - MSVC".
>
> Having downloaded
> http://curl.haxx.se/download/libcurl-7.15.4-win32-nossl.zip from the
> "Win32 - Generic" section, it looks to me that this will work with the MinGW
> compiler (native Win32 port of gcc compiler).

I don't have MSVC so MinGW will be the right for me. To be honest, I
haven't try to recompile libcurl with MinGW for now.

> Aaah ... but hang on ..... are you saying the problem is with WWW::Curl ?
> It's quite likely that *won't* build "straight out of the box", so to
> speak - but some simple hacks at the Makefile.PL should fix that problem.
> What specific problem were you having getting WWW::Curl to build ?

> If you just want a ppm run (for perl 5.8):
> ppm install http://theoryx5.uwinnipeg.ca/ppms/WWW-Curl.ppd

I didn't know that, it's the right thing for me. So I've followed your
clue and I've PPM'ed the WWW::Curl. But now I have some weird thing :

C:\>perl -e "use WWW::Curl::easy; my $curl=WWW::Curl::easy->new();"
Can't locate object method "new" via package "WWW::Curl::easy" at -e
line 1.

C:\>perl -e "use WWW::Curl::easy; my $curl=WWW::Curl::easy::init;"

C:\>perl -e "use WWW::Curl::easy; my $curl=WWW::Curl::easy::init;
$curl->setopt(CURLOPT_URL, "www.google.fr");
$curl->setopt(CURLOPT_VERBOSE,1); my $code = $curl->perform(); print
$code;"

C:\>perl -v
This is perl, v5.8.7 built for MSWin32-x86-multi-thread
(with 7 registered patches, see perl -V for more detail)


Well, I don't understand why, the same code is working under the cygwin
environment :

$ perl -e 'use WWW::Curl::easy; my $curl=WWW::Curl::easy->new();
$curl->setopt(
CURLOPT_URL, "www.google.fr"); $curl->setopt(CURLOPT_VERBOSE,1); my
$code = $curl->perform(); print $code;'
* About to connect() to www.google.fr port 80
* Trying 66.249.91.147... * connected
* Connected to www.google.fr (66.249.91.147) port 80
> GET / HTTP/1.1
Host: www.google.fr
Accept: */*
(... and so on)

I you have any clue, I'll be happy to know it.

Thank you very much for your accurate and useful answer,

Cheers,
Tom

Re: libcurl on Windows boxes ?

wrote in message
..
..
> C:\>perl -e "use WWW::Curl::easy; my $curl=WWW::Curl::easy->new();"
> Can't locate object method "new" via package "WWW::Curl::easy" at -e
> line 1.
>

But shouldn't that be:
C:\>perl -e "use WWW::Curl::Easy; my $curl=WWW::Curl::Easy->new();"

(I expect you need 'Easy' instead of 'easy' as case is important.)

>
> Well, I don't understand why, the same code is working under the cygwin
> environment :
>

If you can load and make use of the package on Cygwin as 'WWW::Curl::easy',
then I can only think that it's a bug in Cygwin :-)

Cheers,
Rob

Re: libcurl on Windows boxes ?

Sisyphus wrote:
> But shouldn't that be:
> C:\>perl -e "use WWW::Curl::Easy; my $curl=WWW::Curl::Easy->new();"
>
> (I expect you need 'Easy' instead of 'easy' as case is important.)
>
> >
> > Well, I don't understand why, the same code is working under the cygwin
> > environment :
> >
>
> If you can load and make use of the package on Cygwin as 'WWW::Curl::easy',
> then I can only think that it's a bug in Cygwin :-)

You're 100% right, on
http://search.cpan.org/~crisb/WWW-Curl-2.0/easy.pm.in it's written
WWW::Curl::easy but using 'Easy' instead is working definitively better
!

So the 'easy' is a cygwin 'feature' :) and just wondering why it didn't
complain about the WWW::Curl::easy::init ... and few other
experimentation :
C:\>perl -e "use WWW::Curl::easy; my $curl=WWW::Curl::easy->new();"
Can't locate object method "new" via package "WWW::Curl::easy" at -e
line 1.

C:\>perl -e "use WWW::Curl::easy; my $curl=WWW::Curl::Easy->new();"
[Ok]

brrr !

Thanks again very much for your quick and precise answer,

Cheers,
Tom

Re: libcurl on Windows boxes ?

"tomazi75@gmail.com" writes:

> You're 100% right, on
> http://search.cpan.org/~crisb/WWW-Curl-2.0/easy.pm.in it's written
> WWW::Curl::easy but using 'Easy' instead is working definitively better
> !
>
> So the 'easy' is a cygwin 'feature' :) and just wondering why it didn't
> complain about the WWW::Curl::easy::init ... and few other
> experimentation :
> C:\>perl -e "use WWW::Curl::easy; my $curl=WWW::Curl::easy->new();"
> Can't locate object method "new" via package "WWW::Curl::easy" at -e
> line 1.
>
> C:\>perl -e "use WWW::Curl::easy; my $curl=WWW::Curl::Easy->new();"
> [Ok]
>
> brrr !

FAT32 & NTFS are both case-insensitive. So when Perl tries to open easy.pm,
it successfully opens and loads Easy.pm instead.

But, Perl name spaces are case-sensitive, hence the "Can't locate object
method" error - even though easy.pm successfully loaded and compiled, the
package declaration in that file is still WWW::Curl::Easy. That's also why
your second test passed.

A more subtle form of this same error is a failure to run import() when a
module is loaded. It's subtle because import() is optional, so not finding
it doesn't actually produce an error. The error comes later, when you try
to call a function that was supposed to be import()ed but wasn't.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

Re: libcurl on Windows boxes ?

Dans l'article , sherm@Sherm-
Pendleys-Computer.local a dit...
>
>"tomazi75@gmail.com" writes:
>
>> You're 100% right, on
>> http://search.cpan.org/~crisb/WWW-Curl-2.0/easy.pm.in it's written
>> WWW::Curl::easy but using 'Easy' instead is working definitively better
>> !
>>
>> So the 'easy' is a cygwin 'feature' :) and just wondering why it didn't
>> complain about the WWW::Curl::easy::init ... and few other
>> experimentation :
>> C:\>perl -e "use WWW::Curl::easy; my $curl=WWW::Curl::easy->new();"
>> Can't locate object method "new" via package "WWW::Curl::easy" at -e
>> line 1.
>>
>> C:\>perl -e "use WWW::Curl::easy; my $curl=WWW::Curl::Easy->new();"
>> [Ok]
>>
>> brrr !
>
>FAT32 & NTFS are both case-insensitive. So when Perl tries to open easy.pm,
>it successfully opens and loads Easy.pm instead.
>
>But, Perl name spaces are case-sensitive, hence the "Can't locate object
>method" error - even though easy.pm successfully loaded and compiled, the
>package declaration in that file is still WWW::Curl::Easy. That's also why
>your second test passed.
>
>A more subtle form of this same error is a failure to run import() when a
>module is loaded. It's subtle because import() is optional, so not finding
>it doesn't actually produce an error. The error comes later, when you try
>to call a function that was supposed to be import()ed but wasn't.
>
>sherm--
>


I wrote the module Win32::StrictFileNames to detect this sort of subtle bug.
It enables (a sort of) case sensitive filenames checking for Win32.
(the Windows file systems NTFS and FAT are case-insensitive but they are
also case-retaining!).

C:\tmp>perl -e "use WWW::Curl::easy; my $curl=WWW::Curl::easy->new();"
Can't locate object method "new" via package "WWW::Curl::easy" at -e line 1.

C:\tmp>perl -e "use Win32::StrictFileNames; use WWW::Curl::easy; my
$curl=WWW::C
url::easy->new();"
Can't locate WWW/Curl/easy.pm in @INC (@INC contains: C:/perl/lib C:/perl/
site/lib .) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

With the 'warn' option the compilation is not aborted but a detailed
diagnostic message is issued:

C:\tmp>perl -e "use Win32::StrictFileNames 'warn'; use WWW::Curl::easy; my
$curl
=WWW::Curl::easy->new();"
Warning: case sensitive mismatch between
File =C:\perl\site\lib\WWW\Curl\easy.pm
Long =C:\perl\site\lib\WWW\Curl\Easy.pm
Short=C:\perl\site\lib\WWW\Curl\Easy.pm
at -e line 1.
Can't locate object method "new" via package "WWW::Curl::easy" at -e line 1.


You can see my small html page for this module:
http://www.bribes.org/perl/wstrictfilenames.html

HTH

--
J-L.M.
http://www.bribes.org/perl

Re: libcurl on Windows boxes ?

jl_morel@bribes.org (Jean-Louis MOREL) writes:

> I wrote the module Win32::StrictFileNames to detect this sort of subtle bug.
> It enables (a sort of) case sensitive filenames checking for Win32.
> (the Windows file systems NTFS and FAT are case-insensitive but they are
> also case-retaining!).

Does your module actually have any Windows-specific code in it? Or did you
choose Win32:: based on the idea it would be useful primarily to Windows
users?

I'm asking because the HFS+ file system used on Macs is (by default at least)
both case-insensitive and case-retaining as well. So your module could be
useful for Mac users too - assuming of course that we *can* use it. ;-)

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

Re: libcurl on Windows boxes ?

Dans l'article , sherm@Sherm-
Pendleys-Computer.local a dit...
>
>jl_morel@bribes.org (Jean-Louis MOREL) writes:
>
>> I wrote the module Win32::StrictFileNames to detect this sort of subtle bug.
>> It enables (a sort of) case sensitive filenames checking for Win32.
>> (the Windows file systems NTFS and FAT are case-insensitive but they are
>> also case-retaining!).
>
>Does your module actually have any Windows-specific code in it? Or did you
>choose Win32:: based on the idea it would be useful primarily to Windows
>users?
>
>I'm asking because the HFS+ file system used on Macs is (by default at least)
>both case-insensitive and case-retaining as well. So your module could be
>useful for Mac users too - assuming of course that we *can* use it. ;-)
>

I fear that the module is Windows-specific.

The module hooks some of the Standard C and Windows-API functions (stat,
rmdir, chdir, CreateFile, ...) used by the perl process. Therefore all call
to one of these functions is redirected toward a similar function that
verifies the case of the path name.

See the white magick in the module XS source:
http://search.cpan.org/src/JLMOREL/Win32-StrictFileNames-0.0 1/StrictFileNames.xs

I don't know if the same thing is feasible on Macs.
I'm a Windows addicted programmer ;-)

--
J-L.M.
http://www.bribes.org/perl

Re: libcurl on Windows boxes ?

Jean-Louis MOREL wrote:
> Dans l'article , sherm@Sherm-
> Pendleys-Computer.local a dit...
>
>>jl_morel@bribes.org (Jean-Louis MOREL) writes:
>>
>>
>>>I wrote the module Win32::StrictFileNames to detect this sort of subtle bug.
>>>It enables (a sort of) case sensitive filenames checking for Win32.
>>>(the Windows file systems NTFS and FAT are case-insensitive but they are
>>>also case-retaining!).
>>
>>Does your module actually have any Windows-specific code in it? Or did you
>>choose Win32:: based on the idea it would be useful primarily to Windows
>>users?
>>
>>I'm asking because the HFS+ file system used on Macs is (by default at least)
>>both case-insensitive and case-retaining as well. So your module could be
>>useful for Mac users too - assuming of course that we *can* use it. ;-)
>>
>
>
> I fear that the module is Windows-specific.
>
> The module hooks some of the Standard C and Windows-API functions (stat,
> rmdir, chdir, CreateFile, ...) used by the perl process. Therefore all call
> to one of these functions is redirected toward a similar function that
> verifies the case of the path name.
>
> See the white magick in the module XS source:
> http://search.cpan.org/src/JLMOREL/Win32-StrictFileNames-0.0 1/StrictFileNames.xs
>
> I don't know if the same thing is feasible on Macs.
> I'm a Windows addicted programmer ;-)
>

I concur -- Win32::StrictFileNames is an XS module with all sorts of
Windows stuff in it. But a generic module ought to be possible if you
override 'use', and maybe 'require'. Of course, the devil is in the
details ...

Tom Wyant

Re: libcurl on Windows boxes ?

harryfmudd [AT] comcast [DOT] net wrote:
> Jean-Louis MOREL wrote:
>
>> Dans l'article ,
>> sherm@Sherm-
>> Pendleys-Computer.local a dit...
>>
>>> jl_morel@bribes.org (Jean-Louis MOREL) writes:
>>>
>>>
>>>> I wrote the module Win32::StrictFileNames to detect this sort of
>>>> subtle bug.
>>>> It enables (a sort of) case sensitive filenames checking for Win32.
>>>> (the Windows file systems NTFS and FAT are case-insensitive but they
>>>> are
>>>> also case-retaining!).
>>>
>>>
>>> Does your module actually have any Windows-specific code in it? Or
>>> did you
>>> choose Win32:: based on the idea it would be useful primarily to Windows
>>> users?
>>>
>>> I'm asking because the HFS+ file system used on Macs is (by default
>>> at least)
>>> both case-insensitive and case-retaining as well. So your module
>>> could be
>>> useful for Mac users too - assuming of course that we *can* use it. ;-)
>>>
>>
>>
>> I fear that the module is Windows-specific.
>>
>> The module hooks some of the Standard C and Windows-API functions (stat,
>> rmdir, chdir, CreateFile, ...) used by the perl process. Therefore all
>> call
>> to one of these functions is redirected toward a similar function that
>> verifies the case of the path name.
>>
>> See the white magick in the module XS source:
>>
>> http://search.cpan.org/src/JLMOREL/Win32-StrictFileNames-0.0 1/StrictFileNames.xs
>>
>>
>> I don't know if the same thing is feasible on Macs.
>> I'm a Windows addicted programmer ;-)
>>
>
> I concur -- Win32::StrictFileNames is an XS module with all sorts of
> Windows stuff in it. But a generic module ought to be possible if you
> override 'use', and maybe 'require'. Of course, the devil is in the
> details ...
>
> Tom Wyant

Follow-up: the devil is indeed in the details. Two issues turned up
after a little thought and fiddling:

1) It does not appear that you can override "use" by simply exporting
"use" from a package and having that call CORE::use.

2) I can not (after all of a few minutes' work) find a good way to tell
whether the file system is case-preserving (but not case-sensitive). The
OS name is not good enough, because many OSes support more than one kind
of file system. I suspect most Mac OS X users are using HFS+, which is
case-preserving. But if you happened to build it on top of the Unix file
system, it is case-sensitive. VMS is either case-sensitive or not
depending on whether your disk is ODS-1, ODS-2, or ODS-5 (and don't ask
me what happened to 3 and 4). I suspect Unix is not case-sensitive if
you happen to be loading modules from a SAMBA disk.

Nothing like making a public statement to find out you're wrong.

Tom Wyant

Re: libcurl on Windows boxes ?

harryfmudd [AT] comcast [DOT] net wrote:
> harryfmudd [AT] comcast [DOT] net wrote:
>
>> Jean-Louis MOREL wrote:
>>
>>> Dans l'article ,
>>> sherm@Sherm-
>>> Pendleys-Computer.local a dit...
>>>
>>>> jl_morel@bribes.org (Jean-Louis MOREL) writes:
>>>>
>>>>
>>>>> I wrote the module Win32::StrictFileNames to detect this sort of
>>>>> subtle bug.
>>>>> It enables (a sort of) case sensitive filenames checking for Win32.
>>>>> (the Windows file systems NTFS and FAT are case-insensitive but
>>>>> they are
>>>>> also case-retaining!).
>>>>
>>>>
>>>>
>>>> Does your module actually have any Windows-specific code in it? Or
>>>> did you
>>>> choose Win32:: based on the idea it would be useful primarily to
>>>> Windows
>>>> users?
>>>>
>>>> I'm asking because the HFS+ file system used on Macs is (by default
>>>> at least)
>>>> both case-insensitive and case-retaining as well. So your module
>>>> could be
>>>> useful for Mac users too - assuming of course that we *can* use it. ;-)
>>>>
>>>
>>>
>>> I fear that the module is Windows-specific.
>>>
>>> The module hooks some of the Standard C and Windows-API functions (stat,
>>> rmdir, chdir, CreateFile, ...) used by the perl process. Therefore
>>> all call
>>> to one of these functions is redirected toward a similar function that
>>> verifies the case of the path name.
>>>
>>> See the white magick in the module XS source:
>>>
>>> http://search.cpan.org/src/JLMOREL/Win32-StrictFileNames-0.0 1/StrictFileNames.xs
>>>
>>>
>>> I don't know if the same thing is feasible on Macs.
>>> I'm a Windows addicted programmer ;-)
>>>
>>
>> I concur -- Win32::StrictFileNames is an XS module with all sorts of
>> Windows stuff in it. But a generic module ought to be possible if you
>> override 'use', and maybe 'require'. Of course, the devil is in the
>> details ...
>>
>> Tom Wyant
>
>
> Follow-up: the devil is indeed in the details. Two issues turned up
> after a little thought and fiddling:
>
> 1) It does not appear that you can override "use" by simply exporting
> "use" from a package and having that call CORE::use.
>
> 2) I can not (after all of a few minutes' work) find a good way to tell
> whether the file system is case-preserving (but not case-sensitive). The
> OS name is not good enough, because many OSes support more than one kind
> of file system. I suspect most Mac OS X users are using HFS+, which is
> case-preserving. But if you happened to build it on top of the Unix file
> system, it is case-sensitive. VMS is either case-sensitive or not
> depending on whether your disk is ODS-1, ODS-2, or ODS-5 (and don't ask
> me what happened to 3 and 4). I suspect Unix is not case-sensitive if
> you happen to be loading modules from a SAMBA disk.
>
> Nothing like making a public statement to find out you're wrong.
>
> Tom Wyant

Yet another thought: you could accomplish almost the same thing by
reverse-engineering the %INC hash into module names, and looking to see
if any of the namespaces are empty. This is an after-the-fact test, and
if you're loading modules on-the-fly you might have to set this up as an
exit handler. There's also the problem that

use Fu::Bar;

corresponds to

BEGIN {require Fu::Bar; Fu::Bar->import (); }

so if you get the case wrong, import() tries to import from the wrong
namespace. Normally this would be fatal, I think, but if there's nothing
to import, Exporter::import will leave (at least) @EXPORT and
@EXPORT_FAIL in the wrong namespace.

Still, this seems to be implementable. One might worry that some of the
pragmas might cause false positives, but in my playing so far I have not
run into this.

Tom Wyant (what! again?)

Re: libcurl on Windows boxes ?

"harryfmudd [AT] comcast [DOT] net" <"harryfmudd [AT] comcast [DOT] net">
wrote in message
..
..
>
> 2) I can not (after all of a few minutes' work) find a good way to tell
> whether the file system is case-preserving (but not case-sensitive).
>

Does the case-preserving question need to be considered ? I would have
thought that the *only* issue is whether the file system is case-sensitive
or not.

Incidentally .... are there any file systems that are *not* case-preserving
?

Cheers,
Rob

Re: libcurl on Windows boxes ?

Sisyphus wrote:
> "harryfmudd [AT] comcast [DOT] net" <"harryfmudd [AT] comcast [DOT] net">
> wrote in message
> .
> .
>
>>2) I can not (after all of a few minutes' work) find a good way to tell
>>whether the file system is case-preserving (but not case-sensitive).
>>
>
>
> Does the case-preserving question need to be considered ? I would have
> thought that the *only* issue is whether the file system is case-sensitive
> or not.

What I meant (but I guess didn't say) was 'case-preserving but not
case-sensitive'.

>
> Incidentally .... are there any file systems that are *not* case-preserving
> ?
>

VMS ODS-1 and ODS-2 are all-uppercase. ODS-5 is case-preserving but not
case-sensitive.

Tom Wyant

Re: libcurl on Windows boxes ?

"harryfmudd [AT] comcast [DOT] net" <"harryfmudd [AT] comcast [DOT] net">
wrote in message news:RJKdnU_Sh8zcJDLZnZ2dnUVZ_t2dnZ2d@comcast.com...
> Sisyphus wrote:
> > "harryfmudd [AT] comcast [DOT] net" <"harryfmudd [AT] comcast [DOT]
net">
> > wrote in message
> > .
> > .
> >
> >>2) I can not (after all of a few minutes' work) find a good way to tell
> >>whether the file system is case-preserving (but not case-sensitive).
> >>
> >
> >
> > Does the case-preserving question need to be considered ? I would have
> > thought that the *only* issue is whether the file system is
case-sensitive
> > or not.
>
> What I meant (but I guess didn't say) was 'case-preserving but not
> case-sensitive'.
>

I was thinking that if you had a module that needed to know if the OS was
case-sensitive or not, when building that module you would simply have the
Makefile.PL do a '-e mAKefiLe.pL' ..... 'true' would mean the file system is
case-insensitive, 'false' would indicate a case-sensitive system. And that's
all you would have to do isn't it ?

Of course that test doesn't cater for the possibility that, on a
case-sensitive system, someone has created a 'mAKefiLe.pL' in the same
directory :-)

Cheers,
Rob

Re: libcurl on Windows boxes ?

Sisyphus wrote:
> "harryfmudd [AT] comcast [DOT] net" <"harryfmudd [AT] comcast [DOT] net">
> wrote in message news:RJKdnU_Sh8zcJDLZnZ2dnUVZ_t2dnZ2d@comcast.com...
>
>>Sisyphus wrote:
>>
>>>"harryfmudd [AT] comcast [DOT] net" <"harryfmudd [AT] comcast [DOT]
>
> net">
>
>>>wrote in message
>>>.
>>>.
>>>
>>>
>>>>2) I can not (after all of a few minutes' work) find a good way to tell
>>>>whether the file system is case-preserving (but not case-sensitive).
>>>>
>>>
>>>
>>>Does the case-preserving question need to be considered ? I would have
>>>thought that the *only* issue is whether the file system is
>
> case-sensitive
>
>>>or not.
>>
>>What I meant (but I guess didn't say) was 'case-preserving but not
>>case-sensitive'.
>>
>
>
> I was thinking that if you had a module that needed to know if the OS was
> case-sensitive or not, when building that module you would simply have the
> Makefile.PL do a '-e mAKefiLe.pL' ..... 'true' would mean the file system is
> case-insensitive, 'false' would indicate a case-sensitive system. And that's
> all you would have to do isn't it ?
>
> Of course that test doesn't cater for the possibility that, on a
> case-sensitive system, someone has created a 'mAKefiLe.pL' in the same
> directory :-)
>
> Cheers,
> Rob
>
>

Well, the other problem (or at least inconvenience) is that
case-sensitivity is a property of the filesystem, not the OS. You would
have to probe every time you wanted to know.

Tom Wyant

Re: libcurl on Windows boxes ?

"Sisyphus" writes:

> I was thinking that if you had a module that needed to know if the OS was
> case-sensitive or not, when building that module you would simply have the
> Makefile.PL do a '-e mAKefiLe.pL' ..... 'true' would mean the file system is
> case-insensitive, 'false' would indicate a case-sensitive system. And that's
> all you would have to do isn't it ?

That will tell you whether the build directory is on a case-sensitive file
system, but that doesn't mean the install directory is also on such a file
system.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

Re: libcurl on Windows boxes ?

"harryfmudd [AT] comcast [DOT] net"
..
..
>
> Well, the other problem (or at least inconvenience) is that
> case-sensitivity is a property of the filesystem, not the OS. You would
> have to probe every time you wanted to know.
>
> Tom Wyant

> That will tell you whether the build directory is on a case-sensitive file
> system, but that doesn't mean the install directory is also on such a file
> system.
>
> sherm--

Tom, Sherm,

Yes ... that's what I was overlooking :-)

Cheers,
Rob

Re: libcurl on Windows boxes ?

Dans l'article , "harryfmudd
[AT]comcast[DOT]net" a dit...
>
>harryfmudd [AT] comcast [DOT] net wrote:
[couic]
>
>Follow-up: the devil is indeed in the details. Two issues turned up
>after a little thought and fiddling:
>
>1) It does not appear that you can override "use" by simply exporting
>"use" from a package and having that call CORE::use.
>
>2) I can not (after all of a few minutes' work) find a good way to tell
>whether the file system is case-preserving (but not case-sensitive). The
>OS name is not good enough, because many OSes support more than one kind
>of file system. I suspect most Mac OS X users are using HFS+, which is
>case-preserving. But if you happened to build it on top of the Unix file
>system, it is case-sensitive. VMS is either case-sensitive or not
>depending on whether your disk is ODS-1, ODS-2, or ODS-5 (and don't ask
>me what happened to 3 and 4). I suspect Unix is not case-sensitive if
>you happen to be loading modules from a SAMBA disk.
>
>Nothing like making a public statement to find out you're wrong.
>


After some fruitless tentatives to override the functions 'require' and
'use', I got a solution: inserting code in @INC.
It's not the ideal solution, but it works on Win32 and Cygwin.

Can you test it on a Mac?
Thanks in advance.

Here is the code of strictModuleNames.pm (a better name?):

#!/usr/bin/perl
use strict;
use warnings;
use File::Spec;

package strictModuleNames;

my @myinc = @INC;
unshift @INC, \✓

sub check {
my ( $coderef, $filename ) = @_;
my ( $FSpath, $path ) = FSpath($filename);
die "Case-sensitive mismatch between filenames:\n$FSpath\n$path\n"
if ( defined $FSpath and ( $FSpath ne $path ) );
return $FSpath;
}

sub FSpath {
my $filename = shift;

foreach (@myinc) {
my $FSpath = $_;
my $path;
if ( -e ( $path = $filename )
or -e ( $path = File::Spec->catfile( $FSpath, $filename ) ) )
{
my ( $volume, $directories, $file ) = File::Spec->splitpath($filename);
my @dirs = File::Spec->splitdir($directories);
my $found = 1;

foreach my $seg (@dirs) {
next unless $seg;
opendir DIR, $FSpath or die $!;
$found = 0;
while ( my $FSseg = readdir(DIR) ) {
if ( uc($FSseg) eq uc($seg) ) {
$FSpath = File::Spec->catdir( $FSpath, $FSseg );
$found = 1;
last;
}
}
closedir DIR;
}
next unless $found;

$found = 0;
opendir DIR, $FSpath or die $!;
while ( my $FSseg = readdir(DIR) ) {
if ( uc($FSseg) eq uc($file) ) {
$FSpath = File::Spec->catfile( $FSpath, $FSseg );
$found = 1;
last;
}
}
closedir DIR;
return ( $path, $FSpath ) if $found;
}
}
return;
}

1;
__END__


--
J-L.M.
http://www.bribes.org/perl

Re: libcurl on Windows boxes ?

jl_morel@bribes.org (Jean-Louis MOREL) writes:

> After some fruitless tentatives to override the functions 'require' and
> 'use', I got a solution: inserting code in @INC.
> It's not the ideal solution, but it works on Win32 and Cygwin.

Actually, it seems pretty good to me. I use the same approach in CamelBones,
to allow things like 'use WebKit' to load and wrap Cocoa frameworks.

I don't know whose idea it was to allow code refs in @INC, but it was sheer
brilliance, IMHO. :-)

> Can you test it on a Mac?

Works for me, on 10.4.7 "Tiger":

Sherm-Pendleys-Computer:~ sherm$ perl -MstrictModuleNames -MTExT::tEmPlAtE \
-e 'print "Howdy!\n"'
Case-sensitive mismatch between filenames:
/Library/Perl/5.8.6/TExT/tEmPlAtE.pm
/Library/Perl/5.8.6/Text/Template.pm
BEGIN failed--compilation aborted.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net