in reply to Re: Bad File Descriptor
in thread Bad File Descriptor

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?

Replies are listed 'Best First'.
Re^3: Bad File Descriptor
by afoken (Chancellor) on Oct 01, 2016 at 19:08 UTC
    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]

        Consider using Registry-Strict instead.

        Registry uses the default mechanism used to "start" or "open" a file, whereas Registry-Strict requires that you explicitly add a (very simple) registry entry explaining Apache how to "start-as-a-CGI" a file (see ScriptInterpreterSource). The difference is not obvious, but it prevents Apache from trying to open files not meant to be executed as CGIs.

        As long as your CGI directory just contains CGIs, there is no difference. But if you accidentally leave a *.txt or *.doc file there and issue a HTTP request for the file, Apache in Registry mode will blindly attempt to start Notepad or Wordpad/Word as a CGI, whereas Apache in Registry-Strict mode won't (and report an error instead).

        I know from experience that at least Windows NT and 2000 will make Notepad / Wordpad / Word hang when started from the Apache service. My guess is that the executable attempts to open a window, but as services generally are not allowed to interact with a Desktop, they get stuck somehow. I haven't checked a more modern Windows, but I guess the behaviour did not change.

        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]
Re^3: Bad File Descriptor
by choroba (Cardinal) on Oct 01, 2016 at 18:44 UTC
    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]
Re^3: Bad File Descriptor
by Marshall (Canon) on Oct 01, 2016 at 18:56 UTC
    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]

In Section Seekers of Perl Wisdom