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"
+);
[download]

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

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
[download]


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


Thanks Again,
Matt

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.

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

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.

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.
[download]

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

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>
[download]

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.
}
[download]

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

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";
[download]

$still_running = kill 0, $pid;
[download]

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
[download]

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

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
[download]


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

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);
}
[download]