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

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.

  • Comment on Re: Re: Re: system call in an CGI perl script, fails on Windows XP

Replies are listed 'Best First'.
Re: Re: Re: Re: system call in an CGI perl script, fails on Windows XP
by sureshr (Beadle) on Sep 30, 2003 at 19:43 UTC
    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
      I'm not quite sure what you mean by "nope." When you run "x.pl", it is the web server (i.e. IIS or Apache or whatever) that determines how to run it. When x.pl calls system("t.pl"), then it is the command interpreter (CMD.EXE) that figures out how to run it. It's two separate programs which are configured separately, so the fact that "x.pl" runs okay just doesn't tell you anything about whether the system call will work.

      I can think of at least three conditions that need to hold for system("t.pl") to work correctly, over and above the condistions necessary for system('c:\perl\bin\perl.exe \htdocs\cgi-bin\t.pl').

      Namely:

      1. t.pl has to be in the current directory or one of the PATH directories.
      2. The ASSOC/FTYPE association has to hold
      3. t.pl has to have Read & Execute allowed for the user under which the web user is running (which is different, in general, from the browser user
      None of these is a matter of Windows 2000 v. Windows XP, but a matter of individual file, directory, registry, and environment variables.