On Oct 28, 2005, at 15:29, Renee Halbrook wrote:
In Mac OS X the newline is \012 and that is what "\n" is eq to. I was
told in MacPerl (for MacOS pre X) the underlying codes of \n and \r
were switched (wrt to the rest of platforms), but still \n is the
logical newline everywhere.
--The specs the file was created from:
Filemaker version 5.5, Mac OS 10.4
The newline character is in this case decimal 013 (oct \015).
I found this out by parsing each character out in java, and looking
at the
byte code.
I thought the "\n" --dec 10, (oct \012) was standard too, but here
is a case
where it is clearly isn't.
I think it might be a Mac issue, since as a test, my collaborator
opened it
in "Text Wrangler" and saved it with Unix safe endings, with the same
results.
I'm not really a Mac person, so this threw me off a bit.
Yeah, some Mac applications write newlines as \015 even today, Text
Wrangler is one of them. And some text editors make the newline even
configurable.
This newline stuff is a PITA, it's easy to develop portable line-
oriented scripts were "portable" means that it works out of the box
as long as the input comes with the runtime platform conventions.
But then there are situations were this just does not work that way:
this Mac gotcha, fat32 file systems mounted on Linux, Windows text
files processed from within Cygwin (configured with Unix
conventions), ....
If you cannot assume the convention is gonna be respected, then you
either program defensively (for instance a CGI doing line-oriented
process of a textarea needs to do this), or else write ad-hoc code as
you did. Each situation needs different degrees of robustness.
I have in my TODO to write an article about newlines someday,
everything is clear once you understand the basic concepts, but it's
an issue that gives often problems until you do.
-- fxn
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
