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

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

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

Replies are listed 'Best First'.
Re: Re: Re: system call in an CGI perl script, fails on Windows XP by Thelonius (Priest) on Sep 30, 2003 at 15:44 UTC
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]
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	[reply]
Re: Re: Re: Re: Re: system call in an CGI perl script, fails on Windows XP by Thelonius (Priest) on Sep 30, 2003 at 20:55 UTC
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: t.pl has to be in the current directory or one of the PATH directories. The ASSOC/FTYPE association has to hold 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.	[reply] [d/l] [select]