Shebang Line

Yes, this is BigRat and I can't for the life of me figure this one out! The documentation DOES NOT say what the Windows shebang line is for exe files.

On my Win2K machine I have 1.3.27 running on port 80 and I have just installed 2.0.49 to run on port 8080.

I first had the problem that I wouldn't execute ANY CGI (I used the httpd.conf which came with the binary no source zip file) and had to add Options Exec+ to the <directory> entry for the CGI directory.

It gives me premature end of headers on 2.0.49 but runs correctly on 1.3.27. (ratprog.exe is actually a "connector" like mod_ajp to talk to my app server)

Importantly it runs out of rewrite, namely I have :-

RewriteRule ^/(.+)\.S$     /cgi-bin/rat.bat

and the ONLY file in cgi-bin is rat.bat containing exactly what I have above.

So, samri, take 2.0.4x, add the rewrite rule and see if you get the same error. What I don't understand is why something simple like this does not work out of the box!

ahoffman: Yes, the line is :-

AddHandler cgi-script .bat

There is also a script alias, came with the file (not changed) which reads :-

# ScriptAlias: This controls which directories contain server scripts.
# ScriptAliases are essentially the same as Aliases, except that
# documents in the realname directory are treated as applications and
# run by the server when requested rather than as documents sent to the client.
# The same rules about trailing "/" apply to ScriptAlias directives as to
# Alias.
#
ScriptAlias /cgi-bin/ "C:/Program Files/Apache Group/Apache2/cgi-bin/"
# ScriptInterpreterSource registry-strict


Now THIS is interesting. If I give the URL :-

http://localhost:8080/cgi-bin/rat.bat?index

the cgi gets called and the App server serves up the top index page, but the browser sees a 500 error.

If I add however to the front of the rat.bat file :-


@echo off
echo content-type: text/plain
echo.
echo echo
c:\ratdir\ratprog S 2040

The browser just displays "echo", which implies that the output from ratprog.exe is NOT being sent forward, or indeed not being outputted, which implies that the headers end "prematurely" since NO output occurred. I'll have to look at the underlying stdout operations. Back later.

PS: Executing rat.bat or ratprog.exe in a command box produces exactly the correct output.

most likely c:\ratdir\ratprog does not return 0

how about adding the "call" statement before the executable?
---
@echo off
echo content-type: text/plain
echo .
call c:\ratdir\ratprog S 2040

I'll try to get a copy of the latest 2.0.49 and see if anything good.

cheers.

hmm, lostany DOS-related memory long ago ..
but was call not only necessary when calling other (.bat) scripts?
Anyway, good hint samri

This is getting extremely frustrating.

Env: Win2K, SP 2, NTFS file store. Apache 2.0.49 for Windows, no source out of box httpd.conf. Added only Rewrite rules, ExecCGI and port 8080.

The .bat file gets executed. The program gets executed. The program returns 0. The program does not seem to be able to write into a file :-

@echo off
echo content-type: text/plain
echo.
echo echo
call c:\ratdir\ratprog.exe GE S 2040 > rat.txt
type rat.txt

The file gets created but there are zero bytes in it.

Next I tried :-

@echo off
echo content-type: text/plain
echo.
echo echo
call c:\ratdir\ratprog.exe GE S 2040 > rat.txt
type rat.txt
echo a message to the browser > rat.txt
type rat.txt

and of course "a message to the browser" appears at the browser.

So, what can I possibly to wrong in a program, which writes to stdout, such that it writes to a command box but not in an Apache script? Is there a special Apache User or what?

Remember, all of this works perfectly on 1.3.27/29 which we have installed at least a dozen customers!

AFAIK  call  is wrong, but I'm not a DOS guru ...

BigRat,

but after the modification to the .bat file, (up to this point), the initial "Error 500" did manage to go away?

and how many "a message to the browser " appears?

I had this (\bin\cat is the unix port of cat cmd.:) running on 2.0.39, win2k sp4.

@echo off
echo content-type: text/plain
echo.
echo echo
c:\bin\cat a.txt > b.txt
type b.txt


and here is the dirlist;
04/01/2004  07:07p                  25 a.txt
04/01/2004  07:07p                   0 b.txt
and the a.txt;
C:\Program Files\Apache Group\Apache2\cgi-bin>more a.txt
a message to the browser
----
but running the same batch file on 1.3, did work.  at least the file a.txt is copied to b.txt

I bet there is something with apache2 that may be causing this (or maybe known behavior).

cheers.

Yes, you get 0 bytes in the file when you do a ">" pipe operation from a Unix program. But the echo pipes correctly into the file.

On 1.3.27 all this works correctly.

Now, I'm having to handle a customer for a couple of days, but I have installed 2.0.49 on the same machine where 1.3.27 is running. And guess what 1.3.27 does not execute CGI scripts. It appends document root to the /cgi-bin/rat.bat which comes out of the rewrite and tries to access that as a file!

I suspect that it is something to do with the permissions in the NTFS file store and I'll have a look at that in a day or so.

Thanks for trying! I'll get to the bottom of this sooner or later!

hmm, slighly remember from early NT days, that there was a problem in cmd.exe with pipes and redirects. sometimes, somehow
sometimes it need space on both ends, sometimes only left, can't remember ...

Another silly question:
  is .bat mapped to command.com instead of cmd.exe ?

>>  is .bat mapped to command.com instead of cmd.exe ?

Under Tools/FolderOptions/FileTypes in Windows Explorer, its not there!
This is normal I think.

I've been fiddling with permissions but so far no success.

> .. Tools/FolderOptions/FileTypes in Windows Explorer
are you trusting M$'s GUI ? not shure if this can be done :-)
Also, there is a registry key which enables calling/loading autoexec.bat when a shell (cmd.exe, command.com) is started.  Just another dragon to check (in case of an buggy autoexec.bat) ..

ahoffman: The problem does not lie in the fact that the files does not get executed, but in that it does not execute correctly.

Look at samri's .bat file. The Unix program c:\bin\cat is NOT able to output to the file b.txt. This is exactly my error. The program, which works perfectly correctly in a DOS Command box and in CGI in Apache1, does not output anything in CGI context in Apache2!

I have downloaded the source of Apache2 and am starting to go through it. The blurb says that the Apache Run Time is now platform dependant (in Apache 1 everything was Posix compliant) and "can make use of platform specific features". What on earth then is stdin and stdout on a Windows platform? That's like asking about the message loop on Unix!

Note to CleanUp volenteers :-

This question has not been abandoned. We are still trying to find a solution or at least ascertain what has gone wrong!

I'm out of ideas according the different behaviour between Apache1 and Apache2, waiting 'til other experts through in new ideas ...

It's something to do with the way the CGI process is created and the std handles are redirected. I've been so busy these last months that I've had no time to look into this further. I though that I'd best post a note just in case cleanup came along.

BigRat - I'm doing some volunteer cleanup work - would this one to be PAQ'd (refund - you didn't get your answer), or to remain open?

I'm working on the answer (better said we are), and I want to post a solution when we find it. Currently the mouse who's doing it is on holiday.

We have had no luck in getting Apache on Win2K to work CGI-wise with our old C-programs. It has been a frustrating time. Clearly I cannot close the question in giving a contribution an answer. But I'll offer to post additional "points for" if the others agree. Otherwise the question will have to go on the deleted list.

you mean c:\ratdir\ratprog.exe when you talk about C-programs?
Then again: did it return status 0, and did it return within apaches allowed timeout?

ahoffman: Yes, naturally. All these programs run OK with Apache 1.3.29 on Win2K, but not with 2.x.y.

this question is 6 months old - and not a solution.  very interesting.

Bigrat: HAve you tried with the latest apache; Which I think had evolved over that period :)

cheeers.

No the last version was 2.0.48. There's nothing in the release notes to suggest any change.

Our problem is that a request comes in, gets rewritten so as to invoke a CGI script, which starts a C program which returns the data. On 1.3.x on Linux and Win32 this works perfectly. But with 2.0.x this only works on Linux. Interestingly the C program IS started and it DOES output data (it actually can't do anything else irrespective of what input it gets). This is very strange since the 1.3.x and the 2.0.x on Linux work straight out of the box! BNut we dammed if we can get the 2.0.x on Win32K to work!

I'll close it for now, but I've still no solution!