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]

On Sat, 6 Sep 2003 14:53:05 +0200, "Alan J. Flavell"
<flavell@mail.cern.ch> 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 <nospam.newton@gmx.li>
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.

[Alan J. Flavell]

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

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]

Alan J. Flavell <flavell@mail.cern.ch> 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?

--
Vlad

[ko]

Vlad Tepes wrote:

> 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 ([url]http://www.cygwin.com/[/url]), crond runs
as a Windows service.

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

HTH - keith

[Chas Friedman]

Alan J. Flavell wrote:
...............

>Thanks! - so I've defined the windows scheduler task to be
>
> wperl c:\path\to\script.pl

...............

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

[Bart Lateur]

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.

[Purl Gurl]

Alan J. Flavell wrote:

(snipped)

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

Configure your program to run on user NT logon.

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

I have stated a number of times Win3.x is the most powerful version
of Windows offered. This is not a comment on Win3.x speed nor its
software support and compatibility.

Win3.x includes a DOS pif (Program Information File) editor which
is powerful and intuitive. This pif editor is missing with subsequent
Windows versions, missing as a user program, but is truly still there.

Create a DOS batch file (.bat) to execute your Perl program. Add this
batch file to Windows' task scheduler. Once you have finished configuring
this batch file for your task scheduler, look in the task scheduler folder.
You will now have a DOS pif file associated with your batch file easily
found by a DOS icon or "list details" selection, under Win Explorer.

Using Windows Explorer, not Windows fileman.exe, right click on this
DOS pif file, select "properties." A very generous set of options will
be presented, including run minimized, close on exit, fonts, screen size
and many other options.

Set your options and you are done.

A direct access pif editor is missing on newer versions of Windows.
However, you can access Windows' hidden pif editor indirectly, if
you know your operating system well.

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


Purl Gurl
--
[url]http://www.purlgurl.net[/url]

[Alan J. Flavell]

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

[Purl Gurl]

Alan J. Flavell wrote:

> Purl Gurl wrote:

> > Alan J. Flavell wrote:

(snipped)

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

Why pay a middleman when you can buy wholesale direct?

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

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

It is a rather common event for techs to not know the
difference between a GUI and an operating system prompt.

Some benefit though, I will be adding this .pif trick of
mine to my Perl tips and tricks on my server. Using this
combination of a .bat file and a .pif file, is a very
efficient and a highly configurable method of running
Perl background processes.

Will wperl allow you to configure, offer options?


Purl Gurl

[Alan J. Flavell]

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
> to your system overhead.

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