in reply to Mangled print output -- any ideas why?

It would appear that you have a carriage return embedded in the end of the string in $ref->{'phone'}.

In the first line of output the program is printing what you expect to the screen up to the end of the phone number. Then it is coming back to the beginning of the same line and printing ", UK Routers" over the top of "Dialing 01 o".

Best to go back and double check the parsing-in of the data (Did you chop a CRLF instead of chomp? Did you import the data from a Mac?) -- or failing that, fix it here.     $ref->{'phone'} =~ s/\015$//; You might be tempted to do:     $ref->{'phone'} =~ s/\r$//; And it may likely work in this case. But be aware that \r varies from system to system.

Replies are listed 'Best First'.
Re: Re: Mangled print output -- any ideas why?
by Anonymous Monk on Jan 08, 2002 at 00:03 UTC
    Right you are dvergin! There is indeed a CR character at the end.
    I think I get what the problem is. My datafile came from a PC and thus has a CRLF in it. But since I am now running this on UNIX (migrating the app from Windows NT/2K to UNIX) chomp only gets rid of the LF and leaves the CR?
    Guess the moral of the story is that straight substitutions are better than using chomp or chop!
    Thanks for the help everyone!
[reply]
      The problem you are seeing with chomp is that Perl uses the line terminator appropriate to the current platform, so if you're in UNIX, Perl chomps just the LF, which is the UNIX value of \n. If you had used the chomp in Win32 you would have removed CRLF, as that is the \n value for that platform. I presume (and welcome corrections) that if your phone data had come from a Mac, the UNIX chomp would not have removed anything, as for UNIX the lines would not appear to have terminators at all (and so the data would have been one long line). This is nicely described in perlport.

      As to fixing it, while chomp appears to be a logical choice, it is an approach of "remove the bad" when you believe you know what the bad is, but as this case has shown you often can't be certain of what the bad is. It is probably safer to reverse this to an approach of "keep the good", with something like tr/0-9//cd, especially since your phone number field is so easy to specify.

      --
      I'd like to be able to assign to an luser

[reply]
[d/l]

In Section Seekers of Perl Wisdom