Chris Wagner wrote: > At 01:46 AM 6/24/05 -0700, $Bill Luebkert wrote: > >>Don't need the binmode on the output file unless you want to remove \r's. > > > Just using binmode in debug environment to prevent implicit newline > translations.
Why - either you want the translation (DOS text mode) or you don't (binary mode). Why bother to ever in your program deal with a CR/\r ? Let the translation do it for you. >>\n is indeed a character. It's a linefeed/newline character. >>It's the underlying OS that adds the CR/\r in front of the >>LF/\n when in text mode. > > Within a certain context it is ^J. From O'Reilly: "All systems use the > virtual "\n" to represent a line terminator, called a newline. There is no > such thing as a newline character. It is an illusion that the operating > system, device drivers, C libraries, and Perl all conspire to preserve. > Sometimes, this changes the number of characters in the strings you read and > write. " That's double-speak. We're not talking about a *virtual* newline character, we're talking that actual ^J/LF/0x0A/\n character and yes it is a character and no it isn't virtual. Just a plain old physical LF/newline character. > So you can never absolutely say what a \n is unless u first define > what context ur in. It just so happens that usually this is the context > where \n eq ^J. Yes I can. A \n is a ^J/LF - always. The \n may be converted by the OS into a \r\n/^M^J/CRLF, but as it is in the Perl program, it is indeed a \n/^J/LF. We're not talking any virtual jargon here. Proof - Perl script: $_ = "1234567890\n"; dumpit ($_); # dumpit does a hex/character dump of a vrbl to STDOUT __END__ Output: 0000 31 32 33 34 35 36 37 38 39 30 0A 1234567890. You'll notice that there is a \n/^J/LF/0x0A/10/012 not any special newline kinda character. Perl only uses a LF for a newline. >>My philosophy would be to never use a \r ever when coding >>output (except to overwrite a line). To cleanup a bad file > > The only time I normally use a \r is when I want to output a DOS format file > on Unix. I use only UNIX line endings on Windoze with the exception of .bat files (like autoexec.bat) and system config files read by the OS. All the rest of the files I generate (Perl scripts and such) are UNIX newlines. When I write data files, I usually write in binmode with no \r's. But if you really wanted a DOSish file on UNIX, you would be correct in doing what you are doing - just can't think of a reason to do it. :) > Some more O'Reilly: "On a Mac, a "\n" is usually represented by "\cM"; just > to make life interesting (and because the standard requires that "\n" and > "\r" be different), a "\r" represents a "\cJ". This is exactly the opposite > of the way that Unix, Plan9, VMS, CP/M, or nearly anyone else does it. So, > Mac programmers writing files for other systems or talking over a network > have to be careful. If you send out "\n", you'll deliver a "\cM", and no > "\cJ" will be seen. Most network services prefer to receive and send > "\cM\cJ" as a line terminator, but most accept merely a "\cJ"." > > Pity. Let's not get into the stupidity of the MAC line ending. That's kinda like asking Windoze builders why they chose to use \ instead of / as a path separator - one of the dumbest design moves in history. -- ,-/- __ _ _ $Bill Luebkert Mailto:[EMAIL PROTECTED] (_/ / ) // // DBE Collectibles Mailto:[EMAIL PROTECTED] / ) /--< o // // Castle of Medieval Myth & Magic http://www.todbe.com/ -/-' /___/_<_</_</_ http://dbecoll.tripod.com/ (My Perl/Lakers stuff) _______________________________________________ Perl-Win32-Users mailing list [email protected] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
