Re: windows one liner to output unix line feed

On Sun, 23 Aug 2009 19:03:54 -0700, sln@xxxxxxxxxxxxxxx wrote:

On Sun, 23 Aug 2009 08:54:40 +0200, Christian Winter <thepoet_nospam@xxxxxxxx> wrote:

sln@xxxxxxxxxxxxxxx wrote:
It really doesen't matter what the :crlf layer does in unix.
It only matters how the console device interprets CR's as a tty.
You can have a thousand CR's and one LF before you print and it will
still print on the next line (Mac may be different).

I think you're mixing up two different things here, one is
text file IO (and the way Perl implements it on different
platforms) and the other is console IO, which would only
apply when piping/directing to or from a perl script.

How could I mix that up. In my example I put the handle in binary
mode. The i/o layers don't care about the handle do they?
Nobodys going to seek the un-seekable. Likewise, the stream gets
a control character that happens to be 0x0a, a line-feed, apparently
free of i/o layer interaction.
Didn't you get that sense?

If his file eol is all CR's ala Mac, then he opened it without an eol
and processed the whole file as one line. Otherwise, a series of
text embedded with just CR's on a console where a CR is a control character,
will result in overwrites of the lines without LF's.

And here you're mixing up Perl's behaviour for input line separators
and output line separators too. Using the "-i" switch, there's no
console involved, Perl simply opens a file and sequencially inserts
what gets passed to print. If the file has been opened with a :crlf
layer, this just means that any newlines encountered in the process
are replaced by a sequence of carriage return plus newline.

And where did you get the notion I was talking about Perls notion
of line seperators or anything related to anything but BINARY output
on a handle ?
I know the layers of Perl better than you do by your response.

What a console shows you when you cat the file contents is a very
different thing.

I find this statement incredible.

If I had a unix machine I could try it out. It seems it would be a major
fopah if Perl didn't get the basic unix console correct, lol.

Again, what's that got to do with a console? You're seriously getting
off the track.


Chris, you should re-read what I wrote. I wasn't writing about Perl
at all. It was all about the device, it had nothing whatsoever to do with
Perl in the slighetest degree!

The output stream to the device was binary, had nothing to do with perlio
layers other than putting the stream in binary before delivering the data
which was odododoaoaododod and other combinations. Devices are themselves
independently act on binary control codes, and CR, LF, FF's are control codes
devices promote to a wide range of different, sometimes visual results, if
thats its nature.


In addition, I was giving examples suggesting that Perl did nothing wrong,
even if the filehandle (apparently not) is not open for binary output.
The suggestion is that the device could be reacting (normally) to embedded
CR's from a cross-platform, or who knows, some binary interaction, by the

Or his device is in a mode that translates control characters differently.

Obviously, the way to debug is to inspect the file, inspect the device mode,
then make a determination. The way NOT to debug, is suspecting Perl a culprit
in something that would have showed up hundreds of thousands of times before

But, apparently, to get the newbies all rieled up on a wild goose chase,
that is seemingly whats happening.