and if MODE is -|, the filename is interpreted as a command that pipes output to us.

Furthermore you have to read line by line (not "slurp") till you either get the desired EOF or you decide to close the $fh.

But first things first

• what is Print , is that a typo of print ?
• what do you do about the error message No such file or directory at /home/jj/eclipse-workspace/ReadGas/ReadFromRadio.pl line 50.

LanX -
yep, 'Print' is 'print'. I pulled it off to format and some MS-auto-corruptor pretty-print capitalized start words.
(file-not-found) I could quiet that with a chdir, sometimes. - I tried pointing to the full path, that didn't work. The file is there, but various implementations of 'open' throw that. I see a fair number of other folks fighting that. But I think 'open' is the wrong tool anyway.
As for 'slurp', not the best term, I get it. The issue I have is there will NEVER be an EOF. I am reading gas usage as reported by the meter. And I can't close the file, either.
So, is there no other way to parse the output of another application as it is presented??

> But I think open is the wrong tool anyway.

I used this approach in the past with great success! 🤷🏽

Maybe try providing an absolute path to the executable.

edit

> The issue I have is there will NEVER be an EOF.

I expect that you get an EOF at least when the process exits or dies. And this case should be covered IMHO.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

Thanx. Back to the books.
I suspected I had not found the right path.

I think the big takeaway is to be ever-lazier (as we know, one of the three cardinal (ha!) virtues of the programmer) - and start by googling to see if someone else has already made the thing I want to do.

The syntax, "open $fh, '-|', $programName" should work as long as you have the path and file permissions correct (make sure execute permission is enabled). Make sure that rtlamr runs in a command window like the example at the URL.

Replace this code....

my @array;
my $i=0;
my $Radio_string ="";

# Need to launch RTLAMR and read the strings coming out.
#  Can pre-filter to just MY meter on the commandline with:
# cd ~/go/bin
# ./rtlamr -msgtype=scm+ --format=json -filterid=101419821, 101419999 
+-unique=false

# Launch the radio
system("/home/jj/go/bin/rtlamr -msgtype=scm+ --format=json -filterid=1
+01419821,101419999 -unique=false");
# slurp the headers
do {
    $Radio_string = $_;
    Print $i;
    Print $Radio_string;
    $i++;
} until $i == 10;

Print("\n-------End of headers.--------\n\n");

# now wait for and process usage reports
#@array = json(system("/home/jj/go/bin/rtlamr -msgtype=scm+ --format=j
+son -filterid=101419821,101419999 -unique=false"));  
    $Radio_string = $_;
    Print $Radio_string;
    @array = json($Radio_string);
Dump(@array);
[download]

use IO::Handle;   #for flush method

my $rtlamr = "/home/jj/go/bin/rtlamr -msgtype=scm+ --format=json -filt
+erid=1 +01419821,101419999 -unique=false";
open my $fh, '-|', $rtlamr or die "unable to start rtlamr program $!";

my $disk_file = "somepath";
open my $disk_fh, '>>', $disk_file or die "unable to open disk history
+ file! $!";

while (<$fh>)  # this is a "blocking" read of radio receiver
{
   print $disk_fh $_;
   $disk_fh-> flush;  # update disk file immediately
}
__END__
That's it.
The analysis program of the disk file, "somepath" is a 
   separate program.
[download]

The loop I show above is infinite - it will never end because there is no EOF. Most of the clock time will be spend just waiting at the while statement with essentially nothing happening otherwise (no CPU cycles for this program). It is possible to do "non-blocking" reads and come up with a scheme to decide that "all the data has been read that can be read at this time". However, that is messy and I don't recommend that.

You can just leave the above program and rl_tcp running all the time. To do the analysis, you should have a 3rd program.

In the analysis program, open the disk file that is being appended by the program above. You can read that filehandle, line by line and you will get an EOF when all of the data has been read. There is nothing wrong with reading a file that is being appended by another program.

However, be aware that very rarely there is the possibility of a premature EOF - meaning that EOF will happen before a newline is encountered. You should allow for that. You can either throw this last line away or just restart the reading process by re-opening the file and reading the file from the beginning again (you just barely missed the last part of the last line).

So, by writing to an intermediate disk file, we solve the "there is no EOF" problem. The disk file will have an EOF when all the data that is currently in it has been read.
Also, rather than counting some fixed number of non-Jason lines to throw away, consider a simple filter, a valid line being one that starts with { and ends with \n. If the last line is a partial one, it won't end in \n.