in reply to Bad File Descriptor

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

[download]
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.

Replies are listed 'Best First'.
Re^2: Bad File Descriptor
by Anonymous Monk on Oct 01, 2016 at 07:11 UTC

    Apache pays attention to shebang even on windows, assoc/ftype dont play a part

[reply]

      ... but only if Apache is configured that way: ScriptInterpreterSource

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
Re^2: Bad File Descriptor
by Milti (Beadle) on Oct 01, 2016 at 15:24 UTC

    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]
      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! I think you nailed the best solution to the problem. I added "ScriptInterpreterSource Registry' to the HTTPD Config file and everything seems to work.

[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,

      [download]
[reply]
[d/l]
      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]

        It appears that you and Choroba are correct. I cleared the top of the program and entered the Shebang line again at the very top and it worked. I also was unaware that Apache, by default, looks for the Shebang line and I have since changed the HTTPD Config file by adding "ScriptInterpreterSource Registry'. I think the problem is solved!

[reply]
Re^2: Bad File Descriptor (updated)
by haukex (Archbishop) on Oct 01, 2016 at 11:36 UTC

    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]

In Section Seekers of Perl Wisdom