The simplest way is to use system and the win32 start command with /b (background) option.

system 'start /b perl script 1>nul 2>&1';
[download]

The redirection isn't necessary if your script produce no output, but it doesn't harm. It would probably better to redirect to a file somewhere so you get a log of any runtime errors or warnings produced. Without the redirection any output from all the processes will be logged to the same console which could become a bit confusing.

Thanks! I couldn't figure out how to make system stop waiting for the script to finish, but start /b seems to do the trick! One question -- I understand 1>nul, but what does the 2>&1 do?

For most POSIX-wannabe platforms, STDIN is handle 0, STDOUT is handle 1, STDERR is handle 2.

• "command >foo" is the same as "command 1>foo".
• "command 2>foo" redirects errors, not output.
• "command 2>&1" ties error output to wherever plain output is going.
Some command shells have different syntax for these, and some are picky about the order ("command foo 2>&1 1>foo" may act differently).

--
[ e d @ h a l l e y . c c ]

2>&1 just says "redirect handle 2 (STDERR by convention) to the same place as handle 1 (STDOUT).

If it was preceded by 1>my.log, then output from both handles would end up in same file. In the case of redirection to nul, this is effectively the same as doing 1>nul 2>nul, but if you tried to do 1>my.log 2>my.log you will get

The process cannot access the file because
it is being used by another process.
[download]

under win32. When the file is opened for the first handle, it is opened for exclusive access, so when the the attempt is made to open it for the second handle you get this error.

Order is also important. If you try  2>&1 1>nul, then you are asking for handle 2 to be redirected to the same the as handle 1, which is the terminal by default (and the same place as the default for handle 2), you then redirect handle 1 to the nul device, but this does not also redirect handle 2, so output to STDERR wil still end up on the terminal and only the output to STDOUT will get bit-bucketed.

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

#!/usr/local/bin/perl -w

# Usage: file-watch.pl file_to_watch interval commands_to_run

# $Id: file-watch.pl,v 1.1.1.1 2003/06/12 12:20:13 evdb Exp $

use strict;

my $file = shift @ARGV;
my $SLEEP = shift @ARGV;
my @CMD = @ARGV;

die "Could not find the file $file.\n" unless -e $file;
my $last_mod = (stat($file))[9];
my $self_mod = (stat($0))[9];

while (1) {
  my $curr_mod = (stat($file))[9];

  if ( $curr_mod > $last_mod ) {
    $last_mod = $curr_mod;
    system @CMD;
  } else {
    sleep $SLEEP;
  }
}
[download]

Create a file test.txt and then try file-watch.pl test.txt 3 'echo It Changed!'. When you touch the test file you will see the message. Greate for watching latex files that you are editing, compiling them, turning the dvi into ps and then sending HUP to gv to refresh the display.

file-watch.pl file.tex 2 "latex file.tex && latex file.tex && dvips -o file.ps file.dvi && killall -HUP gv"

You will of course have to add something else to the command line. You could also use cron if the scripts should run at a certain time.

--tidiness is the memory loss of environmental mnemonics