Re: Until loop

On Tue 02 Apr, Richard Torrens (RiscOS) wrote:
> 
> In article <[email protected]>,
> Richard Torrens (RiscOS) <[email protected]> wrote:
> > 
> [Snip]
> > ATM that's over my head... <Picks up Perl manual and starts reading>.

Which books and/or online docs are you currently using?

The docs supplied with RISC OS Perl are somewhat lacking and
there are no FAQs either. I have found <http://www.perldoc.com/>
to be extremely helpful for filling the gaps in my knowledge.
It contains all the docs for each version of Perl and it is all
searchable too. Highly recommended.

Of course, if you don't have a permanent connection, going on
line may be a rather inconvenient way of looking things up and a
good book may be more appropriate.

> Yes... I clearly need better books on Perl. The ones I have
> say too little about pipes.

Regardless of whether you have access to the online docs,
everyone serious about programming Perl should have a copy of
"Programming Perl" (a.k.a. the Camel Book). The third edition is
much more detailed than the second and works well as both a
reference book and a tutorial. The Camel Book is *the* Perl
bible - the word of god, so to speak. You simply cannot afford
to be without it.

Check it out: <http://www.oreilly.com/catalog/pperl3/>

> The 'fog' above now has a hint of some form, but
> I really don't understand it.
> 
> Any help will be appreciated.

Well, I'm not sure what you don't understand but the main thing
that Steve was doing in his code was using the pipe form of the
open() function and then reading from the filehandle to get the
output of the external command. So for example you could say:

open PIPE, 'show Blackhole$Finished |' or die "Cannot open pipe";
$show_output = <PIPE>; # Gets the first line of output only
close PIPE;

The bar '|' symbol at the end of what would normally be the filename
parameter to open() tells open() that the string is a system command
which is to be run in such a way that its output can be read via
the given PIPE filehandle. You really need to read up on open() to
get the full picture. If you're short on documentation you will find
it on the perldoc site:

    <http://www.perldoc.com/perl5.005_03/pod/func/open.html>

and there is also an open() tutorial here:

    <http://www.perldoc.com/perl5.005_03/pod/perlopentut.html>

It is sometimes useful to be able to read the output from a program
one line at a time using this technique, but for something as
simple as a *show command there's no point going to such lengths.
I would just say:

    $show_output = `show Blackhole\$Finished`;

Which does the same thing all in one go.



> There is a second backup process which is on a 14 day cycle, ATM done
> manually. The idea was to use Perl to detect when the Blackholes were
> reset and to trigger both backup cycles.
> 
> It's  clearly not easy. If both Blackholes are reset together then it's
> indeterminate when the network's going to be ready again,

I'm not clear what you mean by the network not being ready. It's
been a few years since I last used an Access network but I recall
it being possible to access a machine's disc remotely even when
that machine was single tasking. It should therefore be possible
to poll for the existence of a marker file on the remote machine
as I first suggested. Obviously, you've had problems getting that
to work, but why?

> but if I reset sequentially, then the one which starts first
> should be able to tell the parent process when it's finished
> - as now the network will be live again.

I'm still unclear what you mean. Which machine is the "parent process"
running on? Is the parent process a Perl program? Is it responsible
for resetting the two RiscPCs that you are trying to backup? Are the
two RiscPCs being backed up to a third, or to each other, or what?
Is the machine being backed up doing the file copy to the backup
machine, or is the backup machine reading the files of the one
being backed up? Oh, and surely the network is always "live" even
if individual hosts are not listening? Why should it be necessary
to have the daily backups done sequentially in the first place?

> The second reset can start the daily backup process and when this
> ends the calculated 14 day cycle can be run.

Yes, I see why you might want the 14 day backup performed after
the daily one. If you want to detect when the daily process has
finished on a remote machine, why can't you just test for the
existence of a marker file, as has already been suggested? If,
for instance, the remote machine has a program in a taskwindow
waiting for Blackhole to finish single tasking, or a pending
Filer_Run that's effectively doing the same, then it should be
easy to arrange for a marker file to be created at the right time.

> Blackhole doesn't unset its variables when it quits. The idea was to
> unset something in the obey file and detect when this was reset.

I hope my other posting helps with reading system variables, but
I can't see how this helps you because you cannot read the system
variables on a remote machine, and you don't need to read them on
the local machine if you're only waiting for a single tasking
operation to finish anyway. I can't help feeling you're not telling
us the full story.

> But this is problematical - really I should also climb inside
> Blackhole's RunImage and do things there,

Eh? Why do you want to do that?

> but that's not easy as it's compressed Basic.

What? It's free software and the author still wants to hide his
source? That would give me concern about what he's really trying
to hide...  ;-)

-- 
James Taylor <[email protected]>
Based in Southam, Cheltenham, UK.
PGP key available ID: 3FBE1BF9
Fingerprint: F19D803624ED6FE8 370045159F66FD02