Re^2: why isn't split() working here?

Thanks. I was using codepad.org to run some code, and per your suggestion if I switch \n to \r\n, then my code works. I was using codepad.org to run some code using a windows computer, but I still don't quite understand why perl doesn't seemlessly translate \r\n to a \n. When I hit return on a windows computer, I should be entering \r\n--not just \r.

Comment on Re^2: why isn't split() working here?

Replies are listed 'Best First'.
Re^3: why isn't split() working here? by ikegami (Patriarch) on Dec 09, 2010 at 04:35 UTC
Perl does seamlessly convert \r\n to \n on Windows unless you binmode. It would be nice if there was a layer that handled common line endings seamlessly, but noone's gotten around to doing it. It's not that hard, even.	[reply]
Re^4: why isn't split() working here? by Anonymous Monk on Dec 09, 2010 at 07:11 UTC
PerlIO::via/PerlIO::eol	[reply]
Re^5: why isn't split() working here? by ikegami (Patriarch) on Dec 09, 2010 at 16:08 UTC
::via is not relevant if the module is already written. It's also missing some key functionality relating to buffering, so I recommend writing layers in XS instead. Thanks for pointing out :eol, though. This had come up recently on p5p, and noone mentioned it was already written. It's quite unfortunate that it requires a different configuration for input handles than for output handles. It prevents its use as a default layer.	[reply]
Re^3: why isn't split() working here? by Anonyrnous Monk (Hermit) on Dec 09, 2010 at 04:18 UTC
I still don't quite understand why perl doesn't seemlessly translate \r\n to a \n. Presumably, the perl that codepad.org is running is a Unix-built perl, which means it does not add a `:crlf` PerlIO layer to file handles by default (as is done on Windows). The `:crlf` layer is responsible for transparent `\r\n` <—> `\n` linefeed translations (see PerlIO). Adding `binmode DATA, ":crlf"` before slurping in the data should emulate Windows perl behavior on codepad.org.	[reply] [d/l] [select]