|
in reply to Re: why isn't split() working here?
in thread 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. |
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] |
|
|
| [reply] |
|
|
::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] |
|
