PERL Beginners - Re: help slurping a file-- Solved -- Thanks for responses

Author

Re: help slurping a file-- Solved -- Thanks for responses

Jeff 'japhy' Pinyan

2005-10-28, 6:56 pm

On Oct 28, Renee Halbrook said:

> My perl interpreter display does not recognize "\r" for a newline character
> for standard out, so it simply printed the same line over on top of the
> previous line, making it look like it was only reading one line total.
> The slurping was working fine, but the display was not what I anticipating.

That's not Perl's issue. That's your terminal's issue. And it's not an
"issue", because that's what \r is supposed to do. \r is a carriage
return, which only means the cursor is brought back to the beginning of
the line.

(Except maybe on Macs, I don't know. That's weird. I don't use a Mac,
though, so I can't be sure.)

--
Jeff "japhy" Pinyan % How can we ever be the sold short or
RPI Acacia Brother #734 % the cheated, we who for every service
http://www.perlmonks.org/ % have long ago been overpaid?
http://princeton.pm.org/ % -- Meister Eckhart

Xavier Noria

2005-10-28, 6:56 pm

On Oct 28, 2005, at 15:09, Jeff 'japhy' Pinyan wrote:

> On Oct 28, Renee Halbrook said:
>
>
>
> That's not Perl's issue. That's your terminal's issue. And it's
> not an "issue", because that's what \r is supposed to do. \r is a
> carriage return, which only means the cursor is brought back to the
> beginning of the line.
>
> (Except maybe on Macs, I don't know. That's weird. I don't use a
> Mac, though, so I can't be sure.)

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.

-- fxn

Renee Halbrook

2005-10-28, 6:56 pm

> 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.

Renee

Quoting Xavier Noria <fxn@hashref.com>:

> On Oct 28, 2005, at 15:09, Jeff 'japhy' Pinyan 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.
>
> -- fxn
>

>
> --
> To unsubscribe, e-mail: beginners-unsubscribe@perl.org
> For additional commands, e-mail: beginners-help@perl.org
> <http://learn.perl.org/> <http://learn.perl.org/first-response>
>
>
>

Renee Halbrook
Bioinformatics Programmer
The Carnegie Institution of Washington
Department of Plant Biology
260 Panama Street
Stanford, CA 94305

Xavier Noria

2005-10-28, 6:56 pm

On Oct 28, 2005, at 15:29, Renee Halbrook wrote:

>
> --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

Sponsored Links