sureshr has asked for the wisdom of the Perl Monks concerning the following question:

Hello Fellow Monks,

I am trying to call a local program (something like, say, date), via system in my cgi perl script. It just returns -- file not found. This happens only on Windows XP. It works fine on a Win2K box.

Please let me know if anybody has seem a similar problem.

Thank you,
-sureshr
  • Comment on system call in an CGI perl script, fails on Windows XP

Replies are listed 'Best First'.
Re: system call in an CGI perl script, fails on Windows XP
by davido (Cardinal) on Sep 27, 2003 at 17:52 UTC
    You should probably show us a brief example of code that replicates the problem.

    It's possible that your system isn't set up with proper paths to the directory where that system command resides. I would check there first. From within your script try printing the environment's path value and make sure that your system folder is there.

    It's also possible that Perl has a built in version of what you're trying to do through the system command. If it does, that might be your best solution (almost always better to take from within rather than shell out, particularly when dealing with CGI and its inherent security issues).

    For example, if all you want is the date, you can get almost the same thing as `date` with Perl's built-in print scalar localtime;. Of course if you shell out to date you can *change* the date and time, so maybe that's the behavior you're looking for. Anyway, check your path first. And if that doesn't clear it up, post the code that shows the system call so we can see if our eyes spot something wrong.

    Dave

    "If I had my life to do over again, I'd be a plumber." -- Albert Einstein

      Following is the small CGI script that I am trying to call.
      use CGI qw(:standard); sub sendHtmlResponse { print "path=$ENV{PATH}\n"; my $ret = system ("t.pl"); if ($ret != 0) { print "ERROR: calling t.pl failed, ret=[$ret], error=$!\n"; } } print header(); sendHtmlResponse ;
      Following is the t.pl in the above script
      #!perl print "Hello World!\n";
      And, t.pl is in the path that gets printed in the output of my cgi-script above and I always get the ERROR message :(
        Oh, ok, a couple of things. First, when I said print your path, what I really meant was print the system's environment variable "PATH" (the one that looks like this: PATH=C:\;C:\Windows;C:\Windows\System;.....etc). Not the path to perl.

        But I think I see the other problem. If you want to run another Perl script using system, it's possible that your registry doesn't know that .pl means to invoke the Perl intrepreter. On my Windows XP system, when I want to run a Perl script I have to create a copy of the batchfile, runperl.bat, to be scriptname.bat, and run the .bat file, which in turn runs the script. The alternate way of running a Perl script on my WinXP system is to spell it out: perl scriptname.pl.

        So keeping that in mind, it might be necessary for your system command to be system ("perl t.pl");, or since this is CGI, system ("perl -wT t.pl");

        Of course there are other ways of invoking another Perl script from within Perl as well. (use, require, do, fork, open a pipe, or even reading it in as text and using eval on it. It just depends on what you need.)

        UPDATEI forgot to mention one of the most obvious things: Try supplying a complete path instead of just the relative filename of the script you're trying to run. See what happens. The error message "No such file or directory." is telling you something.

        Dave

        "If I had my life to do over again, I'd be a plumber." -- Albert Einstein

        A reply falls below the community's threshold of quality. You may see it by logging in.
Re: system call in an CGI perl script, fails on Windows XP
by Thelonius (Priest) on Sep 28, 2003 at 08:30 UTC
    You need to set the associations for the .pl file extension in the command interpreter. Type this at a command prompt:
    ASSOC .pl=PerlScript FTYPE PerlScript=c:\Perl\bin\perl.exe "%1" %*
    Don't use the START command as Grygonos suggested unless you want to run it asynchronously.

    If you want to mix the output of "t.pl" with the output of the program calling it, you'll need to turn off buffering in the parent program: "$| = 1;"

      As I mentioned previously, for some reason the '.pl' association is not getting inherited by the 'system call'. So, I had to resort to using the full perl interpreter path and the full command path, which works.

      Looking from a broader perspective, this is more of behavioural problem pertaining to XP alone (it works fine on Win2K). The script, without any modifications, works from the command line. I have to investigate further on why it was not working (the failure to inherit certain properties of the parent script -- it should be noted here that the parent script by itself is a .pl script and the correct association is picked for it), if I invoked it via an HTTP request through the web-browser.

      Thanks a lot to all of you, for the solutions.
      -sureshr
        Looking from a broader perspective, this is more of behavioural problem pertaining to XP alone (it works fine on Win2K). The script, without any modifications, works from the command line. I have to investigate further on why it was not working (the failure to inherit certain properties of the parent script -- it should be noted here that the parent script by itself is a .pl script and the correct association is picked for it), if I invoked it via an HTTP request through the web-browser.
        The association for the parent script is done by the web server, not the command interpreter, so that's not relevant.

        If you can run t.pl at the command prompt by just typing "t.pl", then your associations are okay. It could be that the user that that web server is running under has read-access to "t.pl" but not execute access.