in reply to Re: sprintf is printing unexepected output
in thread sprintf is printing unexepected output

BTW,

Why doesn't chomp remove both CR/LF characters? To me, it would be a reasonable and natural thing to do.

Wha'ts the rationale for *not* removing '\r' in this world of mixed Unix, Windows, and Macs?
Where do you want *them* to go today?

Replies are listed 'Best First'.
Re^3: sprintf is printing unexepected output
by sauoq (Abbot) on Dec 29, 2006 at 19:44 UTC
    Why doesn't chomp remove both CR/LF characters?

    It removes $/. By default, $/ is "\n" which is a logical character that may differ from one platform to another. In MacPerl, "\n" equals "\015". On both Windows and Unix platforms "\n" equals "\012". But, on Windows, standard IO translates between "\n" and "\015\012" when the file is opened in text mode. (Which is why you have to use binmode for binary files... where you don't want that translation to take place.)

    I don't really disagree with you. It seems that there'd be a lot less questions about it if chomp just removed all control characters from the end of the string. But changing its behavior now wouldn't really be doable, of course. And, it's easy enough to do what you want with a s///, so it's not really a big issue.

    -sauoq
    "My two cents aren't worth a dime.";
[reply]
[d/l]
[select]
Re^3: sprintf is printing unexepected output
by ferreira (Chaplain) on Dec 29, 2006 at 19:22 UTC
    In Unix world, the end-of-line is simply "\012" (one character). So unless you ask for it, the default behavior is to guess you have a well-behaved Unix file and do the most efficient operation. I think there is support with PerlIO layers to do what you want — but you have to ask for this and take the burden of its cost.
[reply]
[d/l]

In Section Seekers of Perl Wisdom