Suppressing command-prompt window from scheduled task

[Dave Lerner]

[Win2000 SP4]

I've set up a scheduled task that runs a .bat file (that runs a Perl
script). The .bat file starts with "@echo off", and doesn't produce any
console output. The Perl script doesn't produce any console output either.

The only problem is that when the task runs, a command prompt window appears
for about a second, and then closes, which is a minor annoyance. I'd prefer
that the window not appear at all, unless the task needs to display output
or request user input.

Is there any way of preventing the window from appearing?

 

[Pegasus \(MVP\)]

Run the task under an account other than your foreground account.

 

[Jerold Schulman]

[Win2000 SP4]

I've set up a scheduled task that runs a .bat file (that runs a Perl
script). The .bat file starts with "@echo off", and doesn't produce any
console output. The Perl script doesn't produce any console output either.

The only problem is that when the task runs, a command prompt window appears
for about a second, and then closes, which is a minor annoyance. I'd prefer
that the window not appear at all, unless the task needs to display output
or request user input.

Is there any way of preventing the window from appearing?

Yes.

Create an account with appropriate permissions that you use for scheduling.
When you schedule the job to use this new account and run it,
it will run in the background since it is not in the context of the logged on
user.


Jerold Schulman
Windows: General MVP
JSI, Inc.
http://www.jsiinc.com

 

[Dave Lerner]

Thanks, running the task under a user other than the one who's logged in
sounds like a good idea.

The only problem is that the task occassionally does need to display output
and get user input, in which case the command prompt window must be present.
Would this approach allow for that?

I'm trying what may be a better method anyway. I found a Perl module
Win32:aemon http://www.roth.net/perl/Daemon/ that allows Windows services
to be implemented in Perl. I think that's a cleaner approach than running a
..bat file from the task scheduler, at least for my application. Now I just
need to get it working.

 

[Dave Lerner]

Thanks, running the task under a user other than the one who's logged in
sounds like a good idea.

The only problem is that the task occassionally does need to display output
and get user input, in which case the command prompt window must be present.
Would this approach allow for that?

Just in case anyone's interested ...

I solved this problem by splitting the task up into two Perl scripts.

The first script is run by the Windows task scheduler using wperl.exe, which
is the same as perl.exe except that wperl.exe doesn't create a command
prompt window. This script checks whether the second script (which does a
backup) has been run within the preceding 23 hours by examining a status
file. If the second script is due to run, the first script runs it using
exec("perl.exe ..."). Since perl.exe creates the command prompt window, the
second script can do console input/output.