On Fri Dec 11 09:31:44 2015, na...@cpan.org wrote: > 64-bit Windows 10.0.10586. 64-bit perl6 on MoarVM built using MS > Visual Studio 2013 tools. See below for more details. > > I noticed[1] that several tests fail if the test script has Unix line > endings instead of Windows. These tests succeed if the test script is > converted using unix2dos. > Also was fine if you have autoclrf set in Git, fwiw.
> This is problematic behavior. Tests should pass or fail independently > of the EOL convention used in the script file. > > E.g. see test 20 in t\spec\S02-literals\heredocs.t: > > my $e = q:to<END>; > > END > is no-r($e), "\n", 'Heredoc one empty line'; > > This fails with: > > # Failed test 'Heredoc one empty line' > # at t\spec\S02-literals\heredocs.t line 171 > # expected: "\r\n" > # got: "\n" > > That is, when the script source uses Unix line endings, $e contains > "\n", but, because the test is being run on Windows, the comparison > string, "\n" becomes "\r\n". Converting the file with unix2dos fixes > the failures, but that is not a solution. "\n" should not be converted > to "\r\n" behind the scenes in a program. EOL conversion should only > happen at input-output boundaries. > > What happens in this and other tests that fail depending on whether > the test script is saved using Unix or Windows line endings is > contrary to decades of convention of doing EOL translation only at > input-output boundaries. > > For more exploration, see > > [1]: https://www.nu42.com/2015/12/perl6-newline-translation- > botched.html > The logical \n in strings (mirroring logical \n in regexes) didn't work out so well in reality as it did in theory. Now: * We do translation of \r\n graphemes to \n on all input read as text except sockets, independent of platform * We do translation of all \n graphemes to \r\n on text output to handles except sockets, on Windows only * \n is now, unless `use newline` is in force, always \x0A * We don't do any such translation when using .encode/.decode, and of course when reading/writing Bufs to files, providing an escape hatch from translation if needed This hopefully addresses the various issues. Various tests have been updated accordingly.
