in reply to Re: CPAN module unit test issues: OS line endings
in thread CPAN module unit test issues: OS line endings

Thanks toolic,

After I read your comment, I did further testing. This is my Devel::Examine::Subs module, which reads in files and performs work on them.

The test data definitely needs to be converted on Windows, but you made a good point... that might break other things. In Windows, there's not many times you find a Unix-EOL'd file, however I've noticed that all the Perl files in Strawberry Perl are definitely Unix.

I'm going to rework the entire module, so it can identify at the file level what EOLs it has, then act appropriately.

Replies are listed 'Best First'.
Re^3: CPAN module unit test issues: OS line endings
by stevieb (Canon) on Sep 17, 2015 at 23:41 UTC

    So what I ended up doing is setting up a _end_of_line() method, which is called by either one of the two methods that handle the work of managing file names. This method peeks into the file, and sets an environment variable to the file's EOL ('\n' or '\r\n').

    The methods deeper into the application have been modified to use that line ending in the environment variable when they open the respective file later on in the process.

    Works pretty slick.

[reply]
[d/l]
Re^3: CPAN module unit test issues: OS line endings
by Laurent_R (Canon) on Sep 18, 2015 at 09:15 UTC
    In Windows, there's not many times you find a Unix-EOL'd file, however I've noticed that all the Perl files in Strawberry Perl are definitely Unix.
    Are you sure? Although I am very rarely using Perl under Windows and may well be wrong on that, I do not think this is correct.

    Just a quick try under Windows: 

    C:\Users\Laurent>perl -e "print qq{foo\nbar}" > foobar.txt

C:\Users\Laurent>type foobar.txt
foo
bar

    [download]
    Looking at the hexadecimal content of foobar.txt: 
    66 6F 6F 0D 0A 62 61 72                       ; foo..bar

    [download]
    Although I used only "\n" in the script, Perl was clever enough to transform it into a windowish "\r\n" (0D 0A) end of line character combination.

    And, as far as I understand, Perl will also be clever enough, when reading a file and if detecting that it is working under Windows, to look for "\r\n" combinations as ends of lines, so that the whole thing is in fact transparent to the user: you are using "\n" for record separators and chomp, but Perl knows that it should be understood as "\r\n" if the OS is Windows.

    Trouble may occur when processing a Windows-generated file under Unix or vice-versa, but it you're using consistently the OS, Perl will essentially do what you need under the hood, without you even noticing it. So you may think that the Strawberry Perl generated files are Unix-like, but it is most probably not the case.

    I think that you need to understand that to figure out how (and whether) you need special processing for your module under Windows.

[reply]
[d/l]
[select]
      Although I used only "\n" in the script, Perl was clever enough to transform it into a windowish "\r\n" (0D 0A) end of line character combination

      I think stevieb was alluding to the files that *ship* with StrawberryPerl.
      In my version of StrawberryPerl (5.22.0 portable) the files have nix line endings. (At least the few that I checked in perl/vendor/lib did.)
      This can probably vary from one installation to another, depending upon the behaviour of the utility (re line endings) that unpacked the StrawberryPerl distro.

      Cheers,
      Rob
[reply]
        Yeah, syphilis, you're quite probably right ++, it appears that I might have misunderstood what stevieb really meant.
[reply]

In Section Seekers of Perl Wisdom