$line = <FH> returns incomplete lines

[Anno Siegel]

$line = '';
while(1) {
while ( ($line .= <MYLOG> ) )
{
if ($line =~ /[\n]+/) {
print ("GOT THIS: ",$line);
$line = '';
}
}
seek (MYLOG,0, 1);
sleep (1);
}

That code will hang busy if a partial line is read.

The "while( wait_for_level2_io )" condition is the "<>" mode default.
Perl submits a default Level 2 io read request, then waits for the io
device to deliver a complete entry, which could include more than
one "\n" depending on if the callers process was slowed down.

Speed has nothing to do with it.

Perl would return on the last EOL char it gets (there could be
several) OR the EOF condition. Thats why /\n+/ is relavent.
Printing a string with several \n I guess you wouldn't be able
to tell.

You don't know what you are talking about. As long as $/ is unchanged,

Might have to run an assembly program that pumps
multiple \n at high priority to tell for sure.

Meaningless buzzwords.

Anno

 

[Fred]

It works without the seek. Each time some characters are picked up
they are printed. A new 'GOT THIS' message is only printed once a
new line is seen in the input (actually it should not be printed
until at least something has actually been received).


I find that it does... a slightly altered version with a couple of
pattern matching examples...

1) An specific error message is printed once a full line (i.e.
terminated by \n) is found to contain 'error'.
2) A critical message is printed immediately the incoming line is
found to contain 'critical' - there is no wait for the end of
line (the message is repeated as the line is built up until
terminated by \n).

#!/usr/bin/perl

use warnings;
use strict;

open (MYLOG, "/tmp/mylog") or die "Cannot open file: $!";
$|++;

my $line;
my $prefix = "GOT THIS: ";
print "Listening\n";
while ( 1 ) {
while (<MYLOG>) {
print $prefix, $_;
$prefix = '';
$line .= $_;

print "\nCritical *************\n" if $line =~ 'critical';
print "Error =============\n" if /\n/ && $line =~ 'error';

if (/\n/) {
$prefix = 'GOT THIS: ';
$line = '';
} else {
$prefix = '';
}
}
sleep (1);
}
__END__


Axel

Hey Axel,

I just wan't to mention some things about level 1 and 2 io.
Perl doesen't emulate platform IO (that I know of).
If you've ever used terminal emulation you have seen level 1 io,
where the characters are streamed real-time and local
processing might try to buffer, but if its not quick enough
characters are dropped. Thats level 1 io. Level 2 io is
a readline request waiting for the EOL character OR the EOF
condition on your filehandle. Thats what you are doing.
If the writer is doing level 1 io you will be getting EOF
condition most of the time. If writer is level 2 and does a
putline with no EOL you will get EOF, or if the writer
puts a string of escaped crlf's you will get them all
in a single readline. If the reader is too fast, the EOF
condition will always be set. If the reader is slowed
and gets an EOF I don't think the read position will
advance without seek(). So I would leave the seek in.

Btw, so whats wrong with "while ($line.=<MYLOG>)"
is that a Perl error?

gluck

 

[axel]

(e-mail address removed) wrote:

$line = '';
while(1) {
while ( ($line .= <MYLOG> ) )
{
if ($line =~ /[\n]+/) {
print ("GOT THIS: ",$line);
$line = '';
}
}
seek (MYLOG,0, 1);
sleep (1);
}

That code will hang busy if a partial line is read.

The "while( wait_for_level2_io )" condition is the "<>" mode default.
Perl submits a default Level 2 io read request, then waits for the io
device to deliver a complete entry, which could include more than

In your code as soon as an 'incomplete line' (i.e. a line which is not
terminated by \n) is read, the code will loop continuously in the inner
while loop since the condition will evaluate to true until finally
a \n is read and $line reset to ''.

one "\n" depending on if the callers process was slowed down.
Perl would return on the last EOL char it gets (there could be
several) OR the EOF condition. Thats why /\n+/ is relavent.

It will return on the _next_ EOL character (or EOF condition).

Printing a string with several \n I guess you wouldn't be able
to tell. Might have to run an assembly program that pumps
multiple \n at high priority to tell for sure.

If the data creating program prints several \n characters in the same
print operation, this reading script will then read several lines.

Axel

 

[robic]

if ($line =~ /[\n]+/) {
^ ^
^ ^

Those 2 characters can serve no useful purpose, so why are they
there?

Do you understand the code you write?

--

[ Don't quote signatures ]

Staying on topic, please give an example of what code is not
understandable to you.

You misunderstood Tad's point.

You will need to explain what you think the code above does.

Sinan

I think its mis-aligned trash carets... like your brain

 

[robic]

$line = '';
while(1) {
while ( ($line .= <MYLOG> ) )
{
if ($line =~ /[\n]+/) {
print ("GOT THIS: ",$line);
$line = '';
}
}
seek (MYLOG,0, 1);
sleep (1);
}

That code will hang busy if a partial line is read.

It is worse than the OP's solution.

test

 

[robic]

$line = '';
while(1) {
while ( ($line .= <MYLOG> ) )
{
if ($line =~ /[\n]+/) {
print ("GOT THIS: ",$line);
$line = '';
}
}
seek (MYLOG,0, 1);
sleep (1);
}

That code will hang busy if a partial line is read.

The "while( wait_for_level2_io )" condition is the "<>" mode default.
Perl submits a default Level 2 io read request, then waits for the io
device to deliver a complete entry, which could include more than
one "\n" depending on if the callers process was slowed down.
Perl would return on the last EOL char it gets (there could be
several) OR the EOF condition. Thats why /\n+/ is relavent.
Printing a string with several \n I guess you wouldn't be able
to tell. Might have to run an assembly program that pumps
multiple \n at high priority to tell for sure.

 

[robic]

(e-mail address removed) wrote:

$line = '';
while(1) {
while ( ($line .= <MYLOG> ) )
{
if ($line =~ /[\n]+/) {
print ("GOT THIS: ",$line);
$line = '';
}
}
seek (MYLOG,0, 1);
sleep (1);
}

That code will hang busy if a partial line is read.

The "while( wait_for_level2_io )" condition is the "<>" mode default.
Perl submits a default Level 2 io read request, then waits for the io
device to deliver a complete entry, which could include more than
one "\n" depending on if the callers process was slowed down.

Speed has nothing to do with it.

Perl would return on the last EOL char it gets (there could be
several) OR the EOF condition. Thats why /\n+/ is relavent.
Printing a string with several \n I guess you wouldn't be able
to tell.

You don't know what you are talking about. As long as $/ is unchanged,

Might have to run an assembly program that pumps
multiple \n at high priority to tell for sure.

Meaningless buzzwords.

Anno

YAFPE - Yeah another fuckin perl expert...
whats the regex look like on that?
return $1 if ($linebuff =~ /(.*)$\n/)

 

[A. Sinan Unur]

(e-mail address removed) wrote in 4ax.com:

Without giving the impression that this is the only incorrect and
misleading statement you have made, think about:

whats the regex look like on that?
return $1 if ($linebuff =~ /(.*)$\n/)

The pattern you are matching against consists of three parts:

(.*) ... any number of characters
$\ ... The output record separator, undefined by default
n ... The character n

Hence

#! /usr/bin/perl

use strict;
use warnings;

my $s = "xyz\n\n";

if(my $s =~ /(.*)$\n/) {
print "Captured: $1\n";
} else {
print "Didn't match\n";
}

__END__

D:\Home> t
Use of uninitialized value in concatenation (.) or string at D:\Home
\t.pl line 7.
Use of uninitialized value in pattern match (m//) at D:\Home\t.pl line
7.
Didn't match

 

[robic]

(e-mail address removed) wrote:
$line = '';
while(1) {
while ( ($line .= <MYLOG> ) )
{
if ($line =~ /[\n]+/) {
print ("GOT THIS: ",$line);
$line = '';
}
}
seek (MYLOG,0, 1);
sleep (1);
}
That code will hang busy if a partial line is read.

The "while( wait_for_level2_io )" condition is the "<>" mode default.
Perl submits a default Level 2 io read request, then waits for the io
device to deliver a complete entry, which could include more than

In your code as soon as an 'incomplete line' (i.e. a line which is not
terminated by \n) is read, the code will loop continuously in the inner
while loop since the condition will evaluate to true until finally
a \n is read and $line reset to ''.

I don't think so, I think <MYLOG> will always advance the read pointer
but you may be right in as much as the EOF condition will not be
cleared causing an immediate return due to EOF (a few cycles).
To fix it:
while ($line.=<MYLOG>) {
......
seek (MYLOG,0,1);
}
sleep(1);

So now its not a looping wait, its a stop wait.....

It will return on the _next_ EOL character (or EOF condition).

I don't believe this is true at all... This is a complex io
issue Perl has to optimise without wich could cause race
conditions. To find out do the tests..... level 1 io writer vs
level 2 reader, where writer has high priority. Try it out.

 

[robic]

(e-mail address removed) wrote in 4ax.com:

Without giving the impression that this is the only incorrect and
misleading statement you have made, think about:

I wrote it rhetorically man, I know exactly what I wrote and that it
won't return a \n, if u've seen Perl source then just
post what its doing, don't yank my chain, stop showing off your
great fuckin knowledge... what I don't give a rats ass about

 

[A. Sinan Unur]

(e-mail address removed) wrote in 4ax.com:

I wrote it rhetorically man,

Rhetoric, schmotoric, who cares, it was wrong, and needed to be
corrected.

stop showing off your ... knowledge

Not showing off anything, and my knowledge is not that great. If I had
made that kind of error, I sure would have appreciated it if someone had
pointed it out. But that's not even relevant. I did not point it out for
your benefit, but for the benefit of others reading this thread.

You, and your split personality 'Fred', are fairly irrelevant at this
point.

Sinan

 

[robic]

(e-mail address removed) wrote in 4ax.com:


Rhetoric, schmotoric, who cares, it was wrong, and needed to be
corrected.


Not showing off anything, and my knowledge is not that great. If I had
made that kind of error, I sure would have appreciated it if someone had
pointed it out. But that's not even relevant. I did not point it out for
your benefit, but for the benefit of others reading this thread.

You, and your split personality 'Fred', are fairly irrelevant at this
point.

Sinan

Its like readin the funny papers Sinan, if its irrelavent
to you....don't watch, cause I'll be posting along time and
I won't be learning from you.
Does that upset you....

 

[robic]

On 7 Apr 2005 08:08:12 GMT, (e-mail address removed)-berlin.de (Anno
Siegel) wrote:

[snipped Anno's comments]

YAFPE - Yeah another fuckin perl expert...

You put it crudely and sarcastically, yet the gist is quite correct. An
expert he is, one of the more knowledgeable and respected here, and
this is something, I am confident to say, will be *never* true of you.

whats the regex look like on that?
return $1 if ($linebuff =~ /(.*)$\n/)

It is difficult to assess whether it's your manner or your ignorance
that is more disturbing.

YARPA - Yet Another Rude prick Arriving,
Yes your a rude prick. I gues its easy to arive on the thread in the
middle of a technical discussion to just criticise without
contributing anything more than lesson on manners and le ignorance.
Have a happy fuckin life asshole !!!

 

[Sherm Pendley]

YAFPE - Yeah another fuckin perl expert...

Don't worry little boy, if you work real hard and eat all your
vegetables, you can grow up to be a Perl Expert too someday.

sherm--

 

[Sherm Pendley]

Its like readin the funny papers Sinan, if its irrelavent
to you....don't watch

Nonsense needs to be corrected for the sake of other newbies who might
otherwise believe it.

I'll be posting along time and
I won't be learning from you.

I have no doubt about that. You're obviously quite proud of your
ignorance and have no desire to learn anything from anyone.

Does that upset you....

Why should it? Your ignorance doesn't hurt me in the slightest.

sherm--

 

[Sherm Pendley]

YARPA - Yet Another Rude prick Arriving,
Yes your a rude prick. I gues its easy to arive on the thread in the
middle of a technical discussion to just criticise without
contributing anything more than lesson on manners and le ignorance.
Have a happy fuckin life asshole !!!

Do you have anything useful to say?

sherm--

 

[Alan J. Flavell]

(e-mail address removed) wrote:

[nothing worth repeating, evidently]

Do you have anything useful to say?

Happiness is a well-tended killfile. Please do not feed the
troll to discerning usenauts (to mix a metaphor).

 

[rbric]

$line = '';
while(1) {
while ( ($line .= <MYLOG> ) )
{
if ($line =~ /[\n]+/) {
print ("GOT THIS: ",$line);
$line = '';
}
}
seek (MYLOG,0, 1);
sleep (1);
}

That code will hang busy if a partial line is read.

The "while( wait_for_level2_io )" condition is the "<>" mode default.
Perl submits a default Level 2 io read request, then waits for the io
device to deliver a complete entry, which could include more than

In your code as soon as an 'incomplete line' (i.e. a line which is not
terminated by \n) is read, the code will loop continuously in the inner
while loop since the condition will evaluate to true until finally
a \n is read and $line reset to ''.

I don't think so, I think <MYLOG> will always advance the read pointer
but you may be right in as much as the EOF condition will not be
cleared causing an immediate return due to EOF (a few cycles).
To fix it:
while ($line.=<MYLOG>) {
......
seek (MYLOG,0,1);
}
sleep(1);

So now its not a looping wait, its a stop wait.....

Perl best:: loop { test for EOF ( get data } sleep } }
In essence thats all it is for what you are doing, and its
real-time.
There seems to be alot of purported experts here on
os IO subsystems. But I can tell you after doing Telnet
and terminal emulation code for over 20 years, they are lost
in the weeds...
gluck!