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

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" %*

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

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

[reply]
        Nope. We are dealing with two files here. First the parent perl file, say, x.pl and another perl file, say, t.pl, invoked from x.pl via 'system' call.

        1) The browser is able to resolve the association of the parent perl file, ie, x.pl, to use the correct Perl interpreter, whereas not the one in the system within it, t.pl. I mean, system ("full_path/t.pl") would not work.

        2) The parent x.pl has t.pl in its PATH (I tried printing the PATH variable in the html reponse), but still, something like 'system ("t.pl")' in x.pl will not work (only on XP) and I had to use the full path with the perl interperter in full-path in front it in the system call.

        -sureshr
[reply]

In Section Seekers of Perl Wisdom