During testing, t/08-screen.t is failing 4 of 5 tests because of end-of-line mismatches between the result and expected strings. It appears that a trailing CR is being left on the result string, which causes all four failures.
This issue has also been reported on rt.cpan.org (ticket-id:106947).
This appears to be a testing bug, not a module bug.
Given the context of the testing code and the fact that the newline is being thrown out, it appears that only "utf-8" processing is being tested. The end-of-line encoding doesn't seem to be of any concern.
I must note that delving into perl I/O layers makes my brain hurt. But, after some research, I believe the issue at hand is that the STDOUT and STDERR streams are being opened in binary mode but are being expected to return text mode results (i.e., end-of-line/newline == "\n"). The streams either need to be opened in text mode (by appending a :crlf layer) or their output must be massaged more directly, dealing with the various possible end-of-line CRLF combinations.
Likely, the best repair is simply to add :crlf to the layer specification string within _run_helper. Alternatively, again within _run_helper, replace chomp $_ with s/\r?\n?$// (which will correctly strip newlines for the three most common variations: *nix, Win/DOS, and MAC [up to OS-9]).
autarch
commented
8 years ago
During testing,
t/08-screen.tis failing 4 of 5 tests because of end-of-line mismatches between the result and expected strings. It appears that a trailing CR is being left on the result string, which causes all four failures.This issue has also been reported on rt.cpan.org (ticket-id:106947).
This appears to be a testing bug, not a module bug.
Given the context of the testing code and the fact that the newline is being thrown out, it appears that only "utf-8" processing is being tested. The end-of-line encoding doesn't seem to be of any concern.
I must note that delving into perl I/O layers makes my brain hurt. But, after some research, I believe the issue at hand is that the
STDOUTandSTDERRstreams are being opened in binary mode but are being expected to return text mode results (i.e., end-of-line/newline == "\n"). The streams either need to be opened in text mode (by appending a:crlflayer) or their output must be massaged more directly, dealing with the various possible end-of-line CRLF combinations.Likely, the best repair is simply to add
:crlfto the layer specification string within_run_helper. Alternatively, again within_run_helper, replacechomp $_withs/\r?\n?$//(which will correctly strip newlines for the three most common variations: *nix, Win/DOS, and MAC [up to OS-9])..## References
http://www.perlmonks.org/?node_id=549385 @@ https://archive.is/hEXuF http://www.perlmonks.org/?node_id=900026 @@ https://archive.is/5Njlx http://stackoverflow.com/questions/13105361/utf-16-perl-input-output/13106990#13106990 http://stackoverflow.com/questions/17829744/how-to-prevent-perl-to-replace-unix-only-linefeeds/17833422#17833422 http://stackoverflow.com/questions/32013968/create-utf-16le-with-bom-and-crlf-line-separator-on-windows/32014346#32014346 https://en.wikipedia.org/wiki/Newline @@ https://archive.is/kRxQk