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

But you are working on Unix/Linux and so your chomp removes the LF but not the CR.

By default, on all platforms, chomp only ever removes "\n" (linefeed) never "\r" (carriage return). In particular, even on Windows, chomp (by default) does not remove "\r". The reason that this doesn't cause a problem is because if you haven't used binmode on Windows, then reading from a file will transform "\r\n" into "\n".

I find that it is always best to ignore trailing whitespace1 (too many things can add it in and most things don't let you know that it is there). So I almost always use s/\s*$// instead of chomp. This practice prevents the above type of problem as well.

1 Which is one reason why I no longer ever user <<HERE_DOCs, since they can break in the face of trailing whitespace.

- tye        

Replies are listed 'Best First'.
Re^3: sprintf is printing unexepected output (chomp)
by sauoq (Abbot) on Dec 29, 2006 at 19:28 UTC
    By default, on all platforms, chomp only ever removes "\n" (linefeed) never "\r" (carriage return).

    My understanding is a bit different. I agree that chomp removes "\n" by default as $/ defaults to "\n". However, "\n" is not a linefeed, but a "logical newline". On MacPerl, for instance, "\n" means "\015".

    The rest of what you said is true. On Windows "\n" is equal to "\012" just as it is on Unix/Linux but standard IO does the conversion from CRLF to LF if the file is opened in text mode. I didn't mean to imply otherwise; I was just taking a guess at how the situation arose for the OP. Thanks for making it clear though.

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

      Don't let the confusion of perlport and old Macs addle your brain too much. "A" isn't an uppercase A but is merely a logical uppercase A that stands in for the actual bit pattern that applies on that particular platform. When you talk to a SMTP server it doesn't want to hear "HELO" but to hear "HELO" in ASCII so, by the logic of perlport you should never send "HELO" but instead should hard-code the ASCII bit patterns for that. Sounds rediculous, doesn't it? The fact that people don't see it as rediculous when applied to "\n" are several.

      "\n" is quite simply the newline character on the current platform.

      The fact that old Macs claimed to be ASCII systems and so don't provide any translation layers to real ASCII and yet defined "\n" as something other than ASCII newline (but "\n" is still the newline character for old Macs), has caused a lot of broken thinking in the Perl world. I have a few nodes where I go into this in more detail.

      Following the advice in perlport means that you write code that isn't portable unless you are on an ASCII system while just writing "\n" means that your code is portable to every system in the world except for old Macs. The popularity of old Macs vs. the popularity of Perl scripts on non-ASCII systems makes the balance here switch toward favoring portability to one single (somewhat broken) system over just coding portably. But the mental hoops that people have jumped through to try to rationalize the practice of making things that work on old Macs (while ignoring the existance of non-ASCII systems) are impressive and have caused tons of confusion.

      Sorry, I don't have time to go into this further at this time. I'll try to throw in links to my prior discussions of this as I find time.

      - tye        

[reply]
        The fact that old Macs claimed to be ASCII systems and so don't provide any translation layers to real ASCII and yet defined "\n" as something other than ASCII newline (but "\n" is still the newline character for old Macs), has caused a lot of broken thinking in the Perl world.

        I don't find the thinking to which you are referring to be "broken." The broken thinking, if there is any, is in conceptualizing the escape "\n" as popularized by C to be an ASCII character. In the above, even you called it an "ASCII newline". But there is no such thing. The C standard is very clear about "\n" being implementation dependent.

        All that said, it would certainly be easier on everyone if LF were universally accepted as the newline character and we could finally put an end to the suffering that continues to be inflicted upon us by long dead hardware issues and designed incompatibilities.

        -sauoq
        "My two cents aren't worth a dime.";
[reply]
Re^3: sprintf is printing unexepected output (chomp)
by thezip (Vicar) on Dec 29, 2006 at 19:16 UTC

    That's the reason I was looking for -- thanx.

    Where do you want *them* to go today?
[reply]

In Section Seekers of Perl Wisdom