«

It's always a nightmare for me to parse newline characters. No matter \n,
10, 13, I just don't know why some newlines are printed. As the file is
generated by another program, I cannot see the source code, and manual
inspection does not discover any abnormalty.

using chop, chomp or to use replace cannot help. Does anybody have
experience in handling this?

On Sun, 08 Feb 2009 17:05:47 +0800, ela wrote:

> It's always a nightmare for me to parse newline characters. No matter
> \n, 10, 13, I just don't know why some newlines are printed. As the file
> is generated by another program, I cannot see the source code, and
> manual inspection does not discover any abnormalty.
>
> using chop, chomp or to use replace cannot help. Does anybody have
> experience in handling this?

Something like:

chomp;
s/\x0d$//;

Should always do the trick. If not, you have something very strange going
on.

M4

"ela" <> wrote:
>It's always a nightmare for me to parse newline characters. No matter \n,
>10, 13, I just don't know why some newlines are printed. As the file is
>generated by another program, I cannot see the source code, and manual
>inspection does not discover any abnormalty.
>
>using chop, chomp or to use replace cannot help. Does anybody have
>experience in handling this?

Your program is missing a semicolon on line 42.

jue

>
> Something like:
>
> chomp;
> s/\x0d$//;
>
> Should always do the trick. If not, you have something very strange going
> on.
>

Have already tried that before and it doesn't solve...

"Jürgen Exner" <> wrote in message
news:...
> "ela" <> wrote:
>>It's always a nightmare for me to parse newline characters. No matter \n,
>>10, 13, I just don't know why some newlines are printed. As the file is
>>generated by another program, I cannot see the source code, and manual
>>inspection does not discover any abnormalty.
>>
>>using chop, chomp or to use replace cannot help. Does anybody have
>>experience in handling this?
>
> Your program is missing a semicolon on line 42.
>
> jue

line 42????????

Well I've tried :

chop $identiy;
chomp ($identiy);
chop $identiy;
$identity =~ s/\x0d$//;

All fail.

"ela" <> wrote:
>"Jürgen Exner" <> wrote in message
>> "ela" <> wrote:
>>>It's always a nightmare for me to parse newline characters.

What character set are you using? None of the common ASCII-based
character sets (WIndows-1252, ISO-Latin-xxx, Unicode, ...) has a newline
character. See also below.

>>>No matter \n,
>>>10, 13, I just don't know why some newlines are printed. As the file is
>>>generated by another program, I cannot see the source code, and manual
>>>inspection does not discover any abnormalty.
[...]
>> Your program is missing a semicolon on line 42.
>
>line 42????????

Apparently you've never read The Hitchhikers Guide through the Galaxy.

Long form: how do you propose us to fix your code without seeing it?
Have you seen the posting guidelines that are posted here twice a week?

>Well I've tried :
>
> chop $identiy;

This will remove the last character of $identiy.
How do you know that last character is actually the newline?

> chomp ($identiy);

This will remove a trailing $/ from $identiy, whatever $/ may be set to
on your system (usually "\n").
Did you check that $/ matches the tail of $identiy?

> chop $identiy;

This looks identical to the first line?

> $identity =~ s/\x0d$//;

This is working on $identity instead of $identiy. Is that what you meant
to do?

One common problem are format incompatibilities between Windows, Mac,
and Unix. They use different characters/character combinations to denote
a line break. Therefore you should be very explicit about if you are
talking about a line feed character(LF), a carriage return
character(CR), or a logical newline entity of your OS.

Aside of that I suspect that you are looking at the wrong spot and your
real problem is somewhere else, like e.g. a misspelled variable name as
above

As strongly suggested in the posting guidelines please post a
self-contained, minimal program that demonstrates your problem, in your
case including some sample input data, preferable as a _DATA_ section.

jue

"ela" <> wrote in
news:gmm79b$dsa$:

> It's always a nightmare for me to parse newline characters. No matter
> \n, 10, 13, I just don't know why some newlines are printed. As the
> file is generated by another program, I cannot see the source code,
> and manual inspection does not discover any abnormalty.
>
> using chop, chomp or to use replace cannot help. Does anybody have
> experience in handling this?
>
>

You might be encountering NUL characters. I run into the NUL character
problem when working with Windows event logs. Try to use the following on
your data: =~ s/\0/\t/g; You can change "\t" to whatever you need.

Example:
# Get event data
my $streaingTest = $Event{Strings};

# Change NUL to tab for event data
$streaingTest =~ s/\0/\t/g;

....Cos

On Sun, 08 Feb 2009 23:36:39 +0800, ela wrote:


>> Something like:
>>
>> chomp;
>> s/\x0d$//;
>>
>> Should always do the trick. If not, you have something very strange
>> going on.
>>
>>
> Have already tried that before and it doesn't solve...

Funny, did you try hexdumping the files?

M4

On Sun, 08 Feb 2009 23:36:39 +0800, ela wrote:


>> Something like:
>>
>> chomp;
>> s/\x0d$//;
>>
>> Should always do the trick. If not, you have something very strange
>> going on.
>>
>>
> Have already tried that before and it doesn't solve...

BTW, I did mean both statements and in that order.

M4

On Sun, 8 Feb 2009 23:51:54 +0800 "ela" <> wrote:

e> Well I've tried :

e> chop $identiy;
e> chomp ($identiy);
e> chop $identiy;
e> $identity =~ s/\x0d$//;

e> All fail.

Assuming your text is in FILE.TXT:

od -t u1 -t a FILE.txt

What does your text show for the lines that are not correctly processed
by your program?

Ted