Moin,
On Monday 17 September 2007 05:23:14 Alexander Danel via RT wrote:
Show quoted text> Queue: Math-BigInt
> Ticket <URL:
http://rt.cpan.org/Ticket/Display.html?id=29303 >
>
> This is actually I bigger problem, because it happens with many modules
> under the following context:
>
> * Download the module to a MicroSoft PC from CPAN web site (CR-LF).
> * Install the module in a Cygwin system (LF only).
No, modules on CPAN are LF, well, at least modules that are created on Linux
systems - as are mine.
What likely is that you unzipped the module under Windows with WinZIP, and
this (or something similiar) converted the line endings.
If you run:
cpansign --verify
inside Cygwin, I expect the signature check to fail. In this case one could
argue that the module got altered, and is thus broken per se, but I think
making it robust against that line ending change is much easier.
However, any other changes are also likely to break the module. You cannot
simple take the module or .t files, alter them, and then expect anything
still to work. For instance, re-encoding them in something else than UTF-8
would f.i. break any module that has Unicode UTF-8 characters in its
source.
Show quoted text> It might also occur when using the "cpan" automated facility; it
> certainly happened when I did a web download and manual build. Any
> module that has a self referential test is at risk.
Well, any module that is altered after download is at risk :)
Show quoted text> I've also seen it
> happen for a module that has a self-referential method of extracting
> constants from the POD documentation.
>
> So really, this problem needs to be escalated to the CPAN gurus, in my
> opinion. Can you do that?
I don't think so, as the problem is a windows problem, not a CPAN problem.
However, you are right, modules that read their own data (or whatever data)
must expect line endings of either CR-LF, LF or CR (mac) format and many
many don't do.
I fear that the only remedy is to bug report each module where this happens.
What would really help is if someone could setup a cpan-tester machine that
purposefull converts .t files or .pm files to CR-LF and then runs the
testsuite - this would catch most of these problems.
(However, you will get people arguing that their module works only in
unaltered form as downloaded from CPAN :)
It might also be a good idea to amend the documentation about chomp(). I
sent an email to perl5-porters asking about this topic.
All the best,
Tels
--
Signed on Mon Sep 17 18:13:00 2007 with key 0x93B84C15.
View my photo gallery:
http://bloodgate.com/photos
PGP key on
http://bloodgate.com/tels.asc or per email.
"COMPASS [for the CDC-6000 series] is the sort of assembler one expects
from a corporation whose president codes in octal."
-- J.N. Gray
RT for rt.cpan.org