in reply to system call in an CGI perl script, fails on Windows XP

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

Replies are listed 'Best First'.
Re: Re: system call in an CGI perl script, fails on Windows XP
by sureshr (Beadle) on Sep 27, 2003 at 18:32 UTC
    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

        I just tried to use the full path AND with 'perl -wT' and it works. So effectively, it looks are the system is not inherting the parent's properties for some reason.

        I am just confused with this difference in behaviour between in XP & Win2K, than the problem itself. If this is the real problem (property inheritance), then more people would be affected than just me...
        You might also want to note that it works fine on Win2K. And my .pl files are associated to be run using the perl interpreter. So, I think that should not really be a problem.

        Since the PATH is printed from the cgi perl script, I would assume that it would be inherited by the 'system' call within it. Correct me, if I am wrong here. And the perl script that I am calling has the correct program association for execution and also, it is available in the path. The error message says that "No such file or directory", means its not able to locate this file, though the PATH has my script :(

        -sureshr
      A reply falls below the community's threshold of quality. You may see it by logging in.