# Active Perl, Windows scheduler, regular task...

Discussion in 'Perl Misc' started by Alan J. Flavell, Sep 6, 2003.

1. ### Alan J. FlavellGuest

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?

Alan J. Flavell, Sep 6, 2003

2. ### Philip NewtonGuest

On Sat, 6 Sep 2003 14:53:05 +0200, "Alan J. Flavell"
<> wrote:

> 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
--
Philip Newton <>
That really is my address; no need to remove anything to reply.
If you're not part of the solution, you're part of the precipitate.

Philip Newton, Sep 6, 2003

3. ### Alan J. FlavellGuest

On Sat, Sep 6, Philip Newton inscribed on the eternal scroll:

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

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

Alan J. Flavell, Sep 6, 2003

Alan J. Flavell <> wrote:

> 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?

--

5. ### koGuest

ko, Sep 7, 2003
6. ### Bart LateurGuest

Chas Friedman wrote:

> 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>

--
Bart.

Bart Lateur, Sep 9, 2003
7. ### Alan J. FlavellGuest

On Tue, Sep 9, Purl Gurl inscribed on the eternal scroll:

> Alan J. Flavell wrote:
>
> > 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.

>
> 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, Sep 9, 2003
8. ### Alan J. FlavellGuest

On Tue, Sep 9, Purl Gurl inscribed on the eternal scroll:

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

>
> 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

Strange then that you had posted this warning:

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

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

--

"Special offer, today only - free troll feed with every 4 regular
posts" - spotted on another group

Alan J. Flavell, Sep 10, 2003