Active Perl, Windows scheduler, regular task...

[Alan J. Flavell]

Folks, At risk of being ruled OT, I'd appreciate guidance for the
following kind of task which we need to solve, which I'm proposing to
do from an Active Perl script. Assume Win2K or similar (NT4 maybe).

A particular piece of software on laptops is to be kept updated "over
the network" from a distribution server. The laptops are only
intermittently active, and even when they're active they may or may
not have network access.

The network copy that they're to be kept updated against will be
changed (let's say) once a day. So: once an update has been
successful, it's pointless to run it again until the next distribution
is due (although I suppose it would be OK for a low-fat script to
start up, take a look at some last-successful-run timestamp, and then
calmly exit). But we want that if the laptop goes online even once in
a day, then we don't want to miss that day's update.

However, if we set the task scheduler to run the script every couple
of hours, it could well go for days before the scheduled run happens
to hit a moment when the laptop is active and has network access.

If we set it to run every few minutes, the users complain of the task
disrupting their work. Especially as - despite much hunting around -
I don't seem to be able to get the Perl script to run without
flashing-up a DOS window briefly (there must be an answer to that but
somehow I can't find it - you can tell that I'm no great Windows fan)

Is the task scheduler the right approach to this at all, or should I
perhaps be looking to run the script as a system service or something?
This kind of job doesn't seem to be to be an unusual requirement, I
feel sure someone has successfully done something similar. Please?

 

[Philip Newton]

I don't seem to be able to get the Perl script to run without
flashing-up a DOS window briefly (there must be an answer to that but
somehow I can't find it - you can tell that I'm no great Windows fan)

From README.win32 in the source distribution (which gets installed as
"perlwin32", and may be in <ActivePerl
directory>/html/lib/Pod/libwin32.html):

If you want to start a copy
of C<perl> without opening a command-line window, use the C<wperl>
executable built during the installation process. Usage is exactly
the same as normal C<perl> on Win32, except that options like C<-h>
don't work (since they need a command-line window to print to).


Cheers,
Philip

 

[Alan J. Flavell]

From README.win32 in the source distribution (which gets installed as
"perlwin32", and may be in <ActivePerl
directory>/html/lib/Pod/libwin32.html):

Thanks! Sigh, I had dutifully hunted around under the sub-headings
of "Windows Specific", and several other likely places, and drawn a
blank. It never occured to me to read the instructions for _building_
Perl, since I had no intention of "building Perl". Sorry!

If you want to start a copy
of C<perl> without opening a command-line window, use the C<wperl>
executable built during the installation process.

Thanks! - so I've defined the windows scheduler task to be

wperl c:\path\to\script.pl

and can confirm that it works fine, thanks.


I'm still wondering whether I'm heading down the wrong track and ought
to be looking to define a script as a system service, but I think this
approach will work. Thanks for the help!

cheers

 

[Vlad Tepes]

Thanks! - so I've defined the windows scheduler task to be

wperl c:\path\to\script.pl

and can confirm that it works fine, thanks.


I'm still wondering whether I'm heading down the wrong track and ought
to be looking to define a script as a system service, but I think this
approach will work. Thanks for the help!

Apropos running perl as a windows service.

I've read that activestates perl dev-kit compiles perlscripts into
executables that can be run as a service. Are there free alternatives?

 

[ko]

Apropos running perl as a windows service.

I've read that activestates perl dev-kit compiles perlscripts into
executables that can be run as a service. Are there free alternatives?

If you don't mind installing cygwin (http://www.cygwin.com/), crond runs
as a Windows service.

Never used it, but Win32:aemon is on CPAN:
http://search.cpan.org/author/DAVEROTH/Win32-Scheduler_v20000702/lib/Win32/Scheduler.PM

HTH - keith

 

[Bart Lateur]

Is there some documentation for "wperl" somewhere? I can't seem to find
anything about it, and always wondered just what it did...

No, but I can show you how it's created...

Take a look at the Makefile for ActivePerl:


<http://public.activestate.com/gsar/APC/perl-current/win32/Makefile>

Search for "wperl", and you'll see these lines:

copy $(PERLEXE) $(WPERLEXE)
$(MINIPERL) -I..\lib bin\exetype.pl $(WPERLEXE) WINDOWS

So "wperl.exe" is a slightly modified "perl.exe". It has been modified
with the script exetype.pl. If you can't find that, search for
"exetype.bat". "perldoc exetype" will show you the docs... Or you can
see them here:


<http://aspn.activestate.com/ASPN/docs/ActivePerl-5.6/bin/exetype.html>

You can examine the source of the script. What it does is search for a
special short integer (2 bytes -- actually 1 would have been enough) and
modify it. So the difference between "perl.exe" and "wperl.exe" is this
one byte.

So what does it do then? When perl starts up, this byte tells Windows
what kind of executable it is. A CONSOLE type program will create a
console window, also known as a "DOS window", when it starts. A WINDOWS
type program will not. You can always still create one later, if you
want it, using some API calls...


<http://msdn.microsoft.com/library/en-us/dllproc/base/creation_of_a_console.asp>

 

[Alan J. Flavell]

What is the point of a network copy with your stating,

"...may not have network access."

To put it another way: they will have intermittent network access.

Configure your program to run on user NT logon.

Although it's technically feasible to run a task on reboot and/or on
user logon, the fact is that some of these laptops go for days, or all
week or more, with the user staying logged on to the laptop and
connecting it only intermittently to a network (variously by ethernet,
by dialup or by wireless) for IP access (i.e not necessarily
performing an MS network logon).

So, as I tried to make clear at the outset, we need somehow to catch
an interval when the beast is active (not hibernated or sleeping)
_and_ happens to have network access, and run the update task over the
Internet. Without asking the user to remember to manually poke it
once per day, which would be inconvenient and they'd be sure to
forget.

(Sorry, none of this is Perl-specific).

I have stated a number of times Win3.x is the most powerful version
of Windows offered.

Er, well... let's not start on that, but I can see what you're
working up to:

Create a DOS batch file (.bat) to execute your Perl program. Add this
batch file to Windows' task scheduler.

Agreed, it could be done using that compatibility feature via the .pif
file, but actually the wperl solution is doing nicely.

I am curious why you mention Windows 2000 and Windows NT with neither
of these, as default installations, supporting true DOS access.

Probably I should have said "Command window" rather than "DOS window",
yes, but the user distraction was much the same. wperl solved that
issue nicely.

cheers

 

[Alan J. Flavell]

Why pay a middleman when you can buy wholesale direct?

As you pointed out yourself, DOS support in NT is a compatibility
feature, not a natural feature of the OS.

You are running a program which is not needed adding
to your system overhead.

Strange then that you had posted this warning:

As we have learned here just this very day, on this very group, wperl
is the same binary as perl, which we were going to run anyway, apart
from a single option bit.

Anyhow, this is the wrong place to worry about optimising.

all the best