The following Perl statements behave identically on Unixish machines. Do they behave differently on Windows? If yes, is it because of the magic \n?
split m/\015\012/ms, $http_msg;
split m/\015\012/s, $http_msg;
I got a failure on one of my CPAN modules from a Win32 smoke tester. It looks like it's an \r\n vs \n issue. One change I made recently was to add //m to my regexes.
m operator in Perl is used to match a pattern within the given text. The string passed to m operator can be enclosed within any character which will be used as a delimiter to regular expressions.
18, the vertical tab; \w means the 63 characters [A-Za-z0-9_] ; and likewise, all the Posix classes such as [[:print:]] match only the appropriate ASCII-range characters.
So, if you use /./, you'll match any single character (except newline); if you use /(.)/, you'll still match any single character, but now it will be kept in a regular expression memory. For each pair of parentheses in the pattern, you'll have one regular expression memory.
\K resets the starting point of the reported match. Any previously consumed characters are no longer included in the final match. To make the explanation short, consider the following simple Regex: a\Kb.
For these regexes:
m/\015\012/ms m/\015\012/s
Both /m and /s are meaningless.
.
match \n
too.
Your regex doesn't contain .
^
and $
match next to embedded \n
in the string.
Your regex contains no ^
nor $
, or their synonyms.What is possible is indeed if your input handle (socket?) works in text mode, the \r
(\015
) characters will have been deleted on Windows.
So, what to do? I suggest making the \015
characters optional, and split against
/\015?\012/
No need for /m, /s or even the leading m//
. Those are just cargo cult.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With