|
Re: sprintf is printing unexepected output
by sauoq (Abbot) on Dec 29, 2006 at 18:47 UTC
|
What's going on here?
Just a guess here... your data file was created on a Windows box. Hence, its lines end with CRLF. But you are working on Unix/Linux and so your chomp removes the LF but not the CR. You are printing the carriage return (which brings you back to the beginning of the line.)
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
|
|
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.
| [reply]
[d/l] |
|
|
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] |
|
|
|
|
|
|
|
| [reply] |
|
|
That was it -- when I did a substitution to remove both CR and LF (ie. s/[\012\015]//g), it printed correctly.
Thanks for saving my sanity!
Where do you want *them* to go today?
| [reply]
[d/l] |
|
|
| [reply]
[d/l] |
|
|
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] |
|
|
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] |
Re: sprintf is printing unexepected output
by liverpole (Monsignor) on Dec 29, 2006 at 18:54 UTC
|
Hi thezip,
I think what's happening is that you have a carriage return character in the file which isn't getting chomped (the chomp is only handling the newline "\n"), so it's displaying when you print $code, and then the other two variables are getting displayed afterwards.
You don't need to do a print of a sprintf, just use printf by itself.
Furthermore, consider using %32.32s instead of %32s, which will force the string to print with a maximum of 32 characters.
Finally, you don't actually need the quotes on "$code" (thought they don't hurt).
s''(q.S:$/9=(T1';s;(..)(..);$..=substr+crypt($1,$2),2,3;eg;print$..$/
| [reply]
[d/l]
[select] |
Re: sprintf is printing unexepected output
by bart (Canon) on Dec 29, 2006 at 18:57 UTC
|
I suspect there's a CR at the end of your string from the text file, one that didn't get removed by chomp. You could try printing to a file instead of to the console, and check its contents with a hex editor.
Try using
s/[\r\n]+$//
to get rid of any trailing CR+LF.
| [reply]
[d/l] |
Re: sprintf is printing unexepected output
by ysth (Canon) on Dec 29, 2006 at 19:05 UTC
|
Any time you have a problem like this, make sure you examine your variable closely for non-printable characters. I like doing:
use Data::Dumper;
chomp($code = <IFH>);
print Data::Dumper->new( [ $code ] )->Terse(1)->Useqq(1)->Dump();
| [reply]
[d/l] |
|
|
use Data::Dump qw(dump);
chomp($code = <IFH>);
print dump($code);
Data::Dumper has the advantage of being in the core, but Data::Dump usually install smoothly from CPAN. | [reply]
[d/l] |
|
|
You want to be careful about Data::Dump, its actually one of the worst serilization modules around. Its relatively trivial to construct a structure that will make Data::Dump extremely unhappy.
Stick with Data::Dumper, and if you need something easier to read and more powerful and accurate then switch to Data::Dump::Streamer.
---
$world=~s/war/peace/g
| [reply] |
|
|
|
|
|
Re: sprintf is printing unexepected output
by friedo (Prior) on Dec 30, 2006 at 00:53 UTC
|
On a somewhat unrelated note, it's a bit redundant to say print sprintf(...). You can just use printf. | [reply]
[d/l]
[select] |
Re: sprintf is printing unexepected output
by ferreira (Chaplain) on Dec 29, 2006 at 18:50 UTC
|
open (IFH, "data.txt") or die "can't open: $!";
I believe the file is not being opened as you would expect, and then <IFH> is not bringing the content you want.
Update: Never mind -- the CRLF issue that so many monks pointed makes much more sense than my wild wrong guess. | [reply]
[d/l]
[select] |
Re: sprintf is printing unexepected output
by derby (Abbot) on Dec 29, 2006 at 19:02 UTC
|
I would suspect you have some funky control character in data.txt that you don't see through a normal editor. Is this on a *nix system or windows? Can you do an od -xa on data.txt?
| [reply] |