Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Using Proc::Background and Win32

by mmartin (Monk)
on Oct 18, 2013 at 17:12 UTC ( #1058782=perlquestion: print w/ replies, xml ) Need Help??
mmartin has asked for the wisdom of the Perl Monks concerning the following question:

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


Comment on Using Proc::Background and Win32
Select or Download Code
Re: Using Proc::Background and Win32
by Corion (Pope) on Oct 18, 2013 at 17:21 UTC

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

Re: Using Proc::Background and Win32
by dasgar (Deacon) on Oct 18, 2013 at 18:03 UTC

    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

Re: Using Proc::Background and Win32
by BrowserUk (Pope) on Oct 18, 2013 at 18:10 UTC
    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.


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

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

        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.
Re: Using Proc::Background and Win32
by mmartin (Monk) on Oct 18, 2013 at 19:35 UTC
    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

      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

      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

        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

Re: Using Proc::Background and Win32
by mmartin (Monk) on Oct 24, 2013 at 14:50 UTC
    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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1058782]
Approved by keszler
Front-paged by tye
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (11)
As of 2014-10-01 17:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    What is your favourite meta-syntactic variable name?














    Results (31 votes), past polls