I don't make a distinction between "newline" and "linefeed"

And that's the crux of problem. There is a distinction to be made. Not making it just hinders understanding.

On all ASCII systems it is ASCII line feed, except for old Macs where they chose to be "lazy" and try to avoid binmode by defining "\n" in C incorrectly.

There is nothing "incorrect" about defining "\n" as CR with regard to the C standard. Perhaps the C standard should dictate that, if your execution character set is ASCII, then "\n" must map to ASCII LF. If you want to argue that, fine; I don't think I'm well-versed enough in the issues to agree or disagree with such an argument.

I think your comment about choosing 'to be "lazy" and try[ing] to avoid binmode' is way off the mark though. Apparently they didn't choose to be lazy enough and do it like the existing (virtuously) "lazy" ASCII systems out there already happily avoiding binmode. If they had they could have stood with everyone else, sniggering and pointing their fingers at CP/M, OS/2, and DOS.

Thank heavens for POSIX. Now, if we could just get rid of Windows once and for all we could rid ourselves altogether of that stupid "b" in our fopen()s.

"newline character"?? There is no such thing. (:

There isn't in ASCII. There is, on the other hand, in C. It is implementation dependent but always fits in a char and it is represented by the escape sequence '\n'.

Then find a non-ASCII system with Perl on it and open a socket from it to some SMTP server on the internet and send "HELO\015\012" to it and tell me if it works.

While I understand the issue you are pointing out, I don't actually work on non-ASCII systems and don't know whether this is a real problem in practice. Certainly it must have been very well addressed by now? I also fail to see how this is at all specific to Perl. You'd have the same issue if you were, say, writing an MTA in C. Right? ASCII is the lingua franca of the network. If you happen to be working on some EBCDIC variation, you've got to learn to adapt. It's like the byte order issue but at a different level.

I guess I can't disagree that perlport is broken for suggesting that using "\015\012" is a good idea without mentioning any caveats for non-ASCII systems. Have you submitted a doc patch? It seems a simple additional note would suffice.

For whatever it's worth though, perlport hasn't muddled my thinking at all.

-sauoq
"My two cents aren't worth a dime.";

In reply to Re^7: sprintf is printing unexepected output (newline) by sauoq
in thread sprintf is printing unexepected output by thezip

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.