Using Proc::Background and Win32

[mmartin]

Hello All,

Perl: 5.14.4
OS: Win32 (XP)

Does anyone know why if I execute a Perl script using Proc::Background I get an error about 'absolute path' if
I don't include the "perl" keyword before the script name?

Both the calling script and the Background Script reside in the same directory. If I run the EXACT same command
using something like backticks or the 'system()' command it runs just fine, but when Proc:Background does it I get
an error. Any ideas?

I ran both the ASSOC and FTYPE commands in the cmd prompt and they are good. I can run the Perl script from the CLI
without any errors, and without needing to add "perl" before the script name, but for some reason Proc::Background
complains when I don't include that...

>ASSOC .pl
.pl=Perl

>FTYPE Perl
Perl="C:\strawberry\perl\bin\perl.exe" "%1" %*

I assume those are correct since it works from the Command Prompt without needing to add the "perl" keyword...?

Now here are some of the things I've tried:

### THIS ONE GIVE AN ERROR:
$proc = Proc::Background->new("bg_script.pl $ARG1 $ARG2 $ARG3 $ARG4");

### ERROR PRINTED:
C:\Script_dir\main_script.pl: cannot find absolute location of bg_scri
+pt.pl

### IF I INCLUDE THE PATH:
$proc = Proc::Background->new("C:\\Script_dir\\bg_script.pl $ARG1 $ARG
+2 $ARG3 $ARG4");

### ERROR PRINTED (*this one is strange):
C:\Script_dir\main_script.pl: no executable program located at C:\Scri
+pt_dir\bg_script.pl


### THIS ONE WORKS:
$proc = Proc::Background->new("perl bg_script.pl $ARG1 $ARG2 $ARG3 $AR
+G4");

Does anyone know why the Proc::Background command will not run the Perl script without the "perl" keyword before
the script name...?

These other methods seem to work without any errors:

### Backticks --- *THIS ONE WORKS:
`bg_script.pl $ARG1 $ARG2 $ARG3 $ARG4`

### system() --- *THIS ALSO WORKS:
system("bg_script.pl $ARG1 $ARG2 $ARG3 $ARG4");

Is there something with the Proc::Background command I'm missing?
I don't want to include the "perl" keyword because I'm packaging my Perl Scripts using the CavaPackager Program to
make them into exe's...

I also want to keep them as relative paths since this won't be the final location of the program when I'm completed
everything. And both of those script will ALWAYS be in the same directory.


If anyone has ANY hints or suggestions for me, PLEASE feel free, this is getting very frustrating...


Thanks in Advance,
Matt

[Corion]

From looking at the source, and the location of the error message, it seems that Proc::Background makes the error of checking $ENV{PATH} for the program, but fails to know that the current directory on Windows is implied to be on the path.

Maybe you can check whether prefixing your Perl script with the current directory works?

$proc = Proc::Background->new("./bg_script.pl $ARG1 $ARG2 $ARG3 $ARG4"
+);

or

$proc = Proc::Background->new(".\\bg_script.pl $ARG1 $ARG2 $ARG3 $ARG4
+");

[mmartin]

Hey Corion, thanks for the quick reply!

Yea, I actually had that there first since I started writing the script on Linux but still got an error...



# $proc = Proc::Background->new(".\\bg_script.pl $ARG1 $ARG2 $ARG3 $AR
+G4");

C:\Script_dir\main_script.pl: cannot find absolute location of .\bg_sc
+ript.pl


Would it be worth it to add my Scripts Directory to the Path variable or something like that?


Thanks Again,
Matt

[dasgar]

My suspicion is that running the script in the command prompt as well as running in system() is able to leverage the file association that you have configured in Windows -- meaning all .pl files are to be "opened" with perl.exe. And that Proc::Background is not pickup (or using) that file association.

Indeed, looking at Proc::Background's method section of its documentation seems to address the very issue that you are hitting. Basically, the new method is expecting the name (preferably the full path) of an executable to run. In your case, the executable that you are trying to run is perl.exe. However, based on how you are calling the new method, Proc::Background is trying to find an executable named "bg_script.pl.exe", which it can't find.

[mmartin]

Hey dasgar, thanks for the reply!

Humm... Ok sorry, I do see that now in the documentation, thanks.

Yea, I guess maybe I'll try BrowserUK's suggestion and see if that works... His reply is one below
yours in the list.

Thanks Again,
Matt

[BrowserUk]

I ran both the ASSOC and FTYPE commands in the cmd prompt and they are good.

Assoc & ftype are used by the shell to run the appropriate executable.

P::B::W32 uses Win32::Process (which is a thin wrapper around CreateProcess()) which expects the name of the executable as its first argument.

Try passing 'cmd' as the first word.

[mmartin]

Hey BrowserUIK, thanks for the reply!

Ok assuming you meant pass "cmd" before my script name, here's what happened:
        *The first line is just regular output from main_script.pl...
New Proc::Background Command:
$proc = Proc::Background->new("cmd bg_script.pl $speed_ARG \"$ticker_ARG\" $start_ARG $end_ARG $color_ARG");


C:\Script_dir>main_script.pl
EXECUTING bg_script.pl ON WIN32:

A subdirectory or file .exe already exists.
Error occurred while processing: .exe.
A subdirectory or file bg_script.pl already exists.
Error occurred while processing: bg_script.pl.
A subdirectory or file --speed already exists.
Error occurred while processing: --speed.
A subdirectory or file 5 already exists.
Error occurred while processing: 5.
A subdirectory or file --start-in already exists.
Error occurred while processing: --start-in.
A subdirectory or file now already exists.
Error occurred while processing: now.
A subdirectory or file --end-in already exists.
Error occurred while processing: --end-in.
A subdirectory or file end-of-day already exists.
Error occurred while processing: end-of-day.
A subdirectory or file --ticker-color already exists.
Error occurred while processing: --ticker-color.
A subdirectory or file 0xFF0000 already exists.
Error occurred while processing: 0xFF0000.

FYI: The one arg that has the \"...\" around it is because that command might and usually
will contain whitespace.

Where is it getting the ".exe" from in that first error, is that from the "cmd" command? Also, it
looks like it's giving errors on my CLI Args too.

Thanks again for the reply!


Thanks,
Matt

[BrowserUk]

It was worth a try.

BTW: Have you read this in the docs?

For Win32 operating systems:

    The Win32::Process module is always used to spawn background
    processes on the Win32 platform.  This module always takes a
    single string argument containing the executable's name and
    any option arguments.  In addition, it requires that the
    absolute path to the executable is also passed to it.  If
    only a single argument is passed to new, then it is split on
    whitespace into an array and the first element of the split
    array is used at the executable's name.  If multiple
    arguments are passed to new, then the first element is used
    as the executable's name.

    If the executable's name is an absolute path, then new
    checks to see if the executable exists in the given location
    or fails otherwise.  If the executable's name is not
    absolute, then the executable is searched for using the PATH
    environmental variable.  The input executable name is always
    replaced with the absolute path determined by this process.

    In addition, when searching for the executable, the
    executable is searched for using the unchanged executable
    name and if that is not found, then it is checked by
    appending `.exe' to the name in case the name was passed
    without the `.exe' suffix.

    Finally, the argument array is placed back into a single
    string and passed to Win32::Process::Create.</i></blockquote>

Personally, I think the sheer number of generic background process starters on cpan is a string indication that their goal is a flawed concept. I've tried many of them and haven't fond one that works as well as a simple:

if( $^O =~ 'mswin' ) {
    my $pid = system 1, $command;
}
else {
    ##whatever is appropriate on *nix.
}

[mmartin]

It's not paramount that I use the Proc::Background Module, but I do need to run the command in
in the background and have the ability to check on if it's still running or not...

So I tried this way which seemed to execute my script in the background without ANY problems at
all. But when I attempt to check on it's progress I get the same result no matter if it's running
or not.



my $pid = system 1, "bg_script.pl $ARG1 \"$ARG2\" $ARG3 $ARG4 $ARG5";
print "\$pid == '$pid'\n";

my $still_running = kill 0, $pid;
print "BEFORE SLEEP: \$still_running == '$still_running'\n\n";
sleep 10;
$still_running = kill 0, $pid;
print "AFTER SLEEP: \$still_running == '$still_running'\n\n";


The variable $still_running returns "1" on both executions...

Am I not doing the "kill" command correctly? According to Perldoc that is in the correct format, which is:
http://perldoc.perl.org/5.14.2/functions/kill.html

kill SIGNAL, LIST

Where LIST is the processes to check and SIGNAL, when zero, does nothing but check if it's alive still. But
when I run the check:

$still_running = kill 0, $pid;

It returns 1 no matter if it's running or not, I can see that the bg_script.pl is done running after it does
the 10 second sleep. So I'm not sure why it's returning "1" both times?

If I can figure this one out then I can stop killing myself over the Proc::Background Command...


I was also looking at the Win32::Process page, but I saw that on the Proc::Background page it
actually uses the Win32::Process if you PC is Windows. So I guess it wouldn't help to implicitly use that
Module? Does that make sense?
http://search.cpan.org/~bzajac/Proc-Background-1.10/lib/Proc/Background.pm
http://search.cpan.org/~jdb/Win32-Process-0.14/Process.pm


Thanks Again for the replies fellas, much appreciated!

Thanks,
Matt

[BrowserUk]

Try it this way;

Perl> $pid = system 1, 'perl', '-E"sleep 20; say q[done]"';;
Perl> print kill 0, $pid while sleep 1;;
1
1
1
1
1
1
1
1
1
1
1
1
done
1
0
0
0
0
0
0
0

[mmartin]

Hey BrowserUK, thanks again for the reply!

Humm.... I was going to do your example but your first line confused me a bit... Sorry, I'm not brand new to
Perl or anything like that but I'm definitely no expert.

But since my script uses Gtk2, I can't really use the "Sleep" command in the final 'production' script, since
the regular 'sleep' command will pause the processing of Gtk events.

But for pure testing purposes only I tried this and it seemed to work:


my $pid = system 1, ".\\bg_script.pl $ARG1 \"$ARG2\" $ARG3 $ARG4";
print "\$pid == '$pid'\n";

while (kill 0, $pid)
{
    print kill 0, $pid;
    print "\n";
    sleep 1;
}
print "\n\nOUT OF WHILE LOOP\n\n";



______________OUTPUT______________

C:\Script_dir>main_script.pl

$pid == '3144'
1
1
1
1
1
1
0
OUT OF WHILE LOOP


Nice, so it looks like its working that way.... Weird, do you think I had a typo the first time I posted
that, or do you think I can't set it to a variable and check it that way?

And just so you know, in my final script that was working before, with Proc::Background, which was before
I attempted using the CavaPackager to turn this into a standalone executable. I was using a while loop and the
usleep command from --> "use Time::HiRes qw( usleep );" which sleeps so quickly that I was able to continue
processing Gtk commands during each loop. I can show the code for that if your interested...


But anyway, in terms of the Win32::Process, when reading the cpan page for Proc::Background, it sounded like
that Proc::Background Module when run on Win32 it automatically uses the Win32::Process Module.
Is that right, or to try that Win32::Process, do I need to specifically call that, because it looks
like there is quite a good bit of a difference between the two?


Thanks Again,
Matt

[mmartin]

Hey Guys,

As I mentioned in a previous post I was trying to build this script and accompanying scripts/resources
into standalone executable file for Windows. I'm using the CavaPackager program in order to do this,
which also comes with a "Utility" Module called Cava::Packager which contains a bunch of methods you
can use along with your program.

For instance, all image files in my script are called "resources" by CavaPackager and you can set their
location with one of the methods in order for the program to include your virtual path to access these
files later. Well, there is also a method/function you use to execute scripts called from within other
scripts in your CavaPackager's "project".

And, for some reason if I use this Method/Function inside the Proc::Background function, it seems to work.
Even after I built the scripts into executables... The function is called "Cava::Packager::GetScriptCommand".

Here is my working code:

my $TIMEOUT = 30;
my $proc;
# This script is located in same dir as the calling script.
my $bg_script = "bg_script.pl";
......code.....
...............
$proc = Proc::Background->new(Cava::Packager::GetScriptCommand( "$bg_s
+cript", [], $ARG1, "$ARG2", $ARG3));

my $PID = $proc->pid;
my $start_time = $proc->start_time;
my $alive = $proc->alive;

while($alive ne 0)
{
    # This Checks again if it's still running...
    $alive = $proc->alive;

    # This while loop will force Perl::Gtk2 to continue processing 
    # GUI Events while Background process continues executing...
    while (Gtk2->events_pending) {
        Gtk2->main_iteration;
    }
    Gtk2::Gdk->flush;

    $timeout_current = time;    #->Sets the current time (EPOCH)

    # Get the difference in time from the current time and the
    # start time, to check if we hit the TIMEOUT limit of 30 sec
    $timeout_diff = $timeout_current - $timeout_start;

    # If the time difference is >= the TIMEOUT limit of 30 sec, then
    # use 'last' to break out of the loop...
    if ($timeout_diff >= $TIMEOUT) {
        $timed_out = 1;
        last;
    }

    # Sleep for 1000 milliseconds
    usleep(1000);
}


So it seems that I am able to use Proc::Background after all...!

I just wanted to thank everyone for their replies, much appreciated!


Thanks Again,
Matt