|
Re: Bad File Descriptor
by Marshall (Canon) on Sep 30, 2016 at 23:50 UTC
|
On Windows, the path in the #! line does not matter, although the -w switch does matter. You actually don't even need a "#!" line at all. For Windows, the associations and file type info is what matters and is how Windows decides what program to run. On my local machine I get:
C:\Documents and Settings\xxx>assoc.pl
.pl=Perl
C:\Documents and Settings\xxx>ftype Perl
Perl="C:\Perl\bin\perl.exe" "%1" %*
The association says that .pl is a Perl file. The ftype tells Windows what program to run and the path there definitely does matter!
Make sure that these are set correctly for whatever user that Apaches runs under. | [reply]
[d/l] |
|
|
| [reply] |
|
|
| [reply] |
|
|
Hi Marshall,
On Windows, the path in the #! line does not matter
I know what you mean (it doesn't matter for finding the location of the interpreter) but I think that wording is a little misleading - from perlrun:
The #! line is always examined for switches as the line is being parsed.
Update: Apparently I can't read today :-/ Sorry Marshall. Off to get more caffeine.
Regards,
-- Hauke D
| [reply]
[d/l] |
|
|
Thanks for the feedback. I had read that Windows does not require a Shebang line, but, while that was apparently true when I was running Apache 1.3 on a Windows 2003 Server it isn't the case with Apache 2.2 on Windows Server 2012, at least not the way my instances are or aren't configured. When the new server was set up and I tried to migrate and run the cgi programs that were on the old server nothing would run. After many inquiries and much research someone, similar to you, suggested the problem was the lack of a Shebang line and that that line had to include the exact path to the Perl executable, i.e. #!C:/Perl/bin/perl. Once I inserted that into the programs they all were recognized and perfectly executed. Thus, the reason I can't understand why, all of a sudden, I have two programs that aren't recognized and the constant message indicating the lack of #! Something is amiss. But what?
| [reply] |
|
|
Isn't there something invisible before the shebang line? A BOM, maybe?
($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
| [reply]
[d/l] |
|
|
I had read that Windows does not require a Shebang line, but, while that was apparently true when I was running Apache 1.3 on a Windows 2003 Server it isn't the case with Apache 2.2 on Windows Server 2012, at least not the way my instances are or aren't configured.
Windows does not require a shebang line, but Apache does if configured that way. ScriptInterpreterSource set to Script requires a shebang line, set to Registry uses the default Windows mechanism, set to Registry-Strict reads the registry subkey Shell\ExecCGI\Command. Script is the default since the directive was introduced (in 1.3.6, according to apacheweek). Before that, the Apache behaviour was equivalent to Registry.
If the old Apache was configured to use mod_perl and Apache::Registry, Apache would not care about the Windows registry or the shebang line, but instead use the perl interpreter running in mod_perl.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
|
Thanks for the info. I didn't know that about Apache quirk on Windows. I do most of my work on Windows (but all cgi stuff on Unix). I put /usr/bin/perl in the Shebang line so that I can test on windows and can transfer the program to the Unix box.
This is a weird one! So you have two programs with same Shebang line, in same directory, same permissions and one works and the other doesn't. This is a weird thought, but maybe these 2 shebang lines just look the same, but really aren't? There could be a non-printing control character or maybe the line endings are different and Apache cares about that? Something has to be different and we've ruled a lot out. Unix ends lines with a simple LF while Windows uses a CR, LF (carriage return, line feed). That difference would be invisible to you in the text editor. Compare the binary of the first couple of lines and see if you can discern any difference at all between the "works" and "doesn't work" files. This shouldn't matter (Perl and in most cases Windows doesn't care), but maybe somehow Apaches does care? I know this is a long shot, but geez there has to be something different and I'm running out of ideas as to what that could be.
update: Yes as choroba points out, there could also be something "invisible" before the line starts, a BOM. A binary compare should yield a definitive answer.
| [reply] |
|
|
Re: Bad File Descriptor ( apache don't know how to spawn child process )
by Anonymous Monk on Sep 30, 2016 at 21:54 UTC
|
What is the full path to perl?
Apache is saying C:/Perl/bin/perl isn't a program it can launch
If that is where the file really is try the full name of C:/Perl/bin/perl.exe
Heck even try C:\Perl\bin\perl.exe for good measure
| [reply]
[d/l]
[select] |
|
|
The same Shebang line, #!C:/Perl/bin/perl, works on other cgi programs on this server. The location of the perl .exe file is as noted, C:/Perl/bin/perl, where perl is the executable .exe file. I will try both your suggestions but I don't understand why something might work one time and not the next.
| [reply] |
|
|
The same Shebang line, #!C:/Perl/bin/perl, works on other cgi programs on this server.
In that case check file permissions. The error message you quoted does say "cgiprogram.pl is not executable" thats a permissions thing.
| [reply] |
|
|
|
|
