Andy:
On Mon, Jan 05, 2015 at 01:22:34PM -0600, Andy Bach wrote:
> And Perl should be noting which OS you're on and 'tranlating' "\n" into the
> appropriate sequence. Though I get the same output for:
> $ perl -e '{ local $\ = "\n"; print "hi" }' | perl -ne "print( ord($_),
> qq{ }) foreach split(//)"
> 104 105 10
>
> on, Mac, windows and Linux.I think in most programming languages the \n escape sequence typically becomes a literal LF character in memory. It is only when you write to a text file stream that it gets translated (if then). Obviously for UNIXes (e.g., GNU+Linux, BSDs, MAC OS X) there is no translation since the newline character in UNIX is LF. In Windows, it would turn LF into CRLF on the way out, but only for text streams. If you write with binmode set then it should be literal again. You can still end up with CRLF in memory in Windows if you read from a binary stream, which I think includes non-native encoded streams (e.g., UTF-8 via IO layer). I think, but I'm not sure, that a plain text stream in Windows would convert CRLF to LF when reading too, but I don't have a Windows machine to test on right now (that feels good). If so that would explain why you get the same output on each platform. In Windows the first perl writes h i CR LF to the pipe and the second perl reads it back into memory as h i LF. I'm not even sure if that's something that perl does or something that the C runtime or OS is doing for us. In Windows you should be able to experiment with tee(1) in the middle and/or binmode on either or both ends of the pipe anyway. Regards, -- Brandon McCaig <bamcc...@gmail.com> <bamcc...@castopulence.org> Castopulence Software <https://www.castopulence.org/> Blog <http://www.bamccaig.com/> perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }. q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.}; tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'
signature.asc
Description: Digital signature
