Redirect error messages

I am working on a ruby cgi script on a host that refuses to give me ssh access. Therefore I am developing locally and then uploading blindly. I am getting some errors after upload that the host seems to think are my fault but all that I can get access to for debugging is the cryptic apache error log that just tells me

Premature end of script headers

The script runs on my mac. I don't know how they have their servers setup(RedHat) so I can't emulate the problem. I would like to be able to see what exactly my script is giving as error output but can't seem to find out how I redirect the error stream to a log file I would setup on the server.

Anyone care to help me figure this out before I have to cancel my hosting service and waste time moving the domain?

Thank you,
Matthew Margolis

Matthew Margolis <mrmargolis@wisc.edu> wrote in
news:41F5A084.7010107@wisc.edu:

Anyone care to help me figure this out before I have to cancel my
hosting service and waste time moving the domain?

I'm a newbie to ruby, but try the following:
$stderr = File.open('error.log', 'w+')
$stdout = $stderr

In theory, both stdout and stderr should be redirected to the file.

Ed.

Matthew Margolis wrote:

Premature end of script headers

The script runs on my mac. I don't know how they have their servers setup(RedHat) so I can't emulate the problem.

This is so obvious I am sure you checked it already, but are you sure the path to the ruby binary is right at the top of the script? You could use the /usr/bin/env ruby trick to ensure that it finds the ruby binary.

Eric

No idea about the exact setup, but often, having CGI access like you
do is almost as good as having SSH access. In fact, I'm sure there
are many CGI scripts out there that give you pseudo-shell access with
a neat web interface.

For starters you could try something like:

#!/bin/sh
echo "Content-type: text/html"
echo
echo "<pre>"
cat /etc/passwd
echo "</pre>"

You might not have access to the real /etc/passwd in particular, but
you get the idea here.

For what it's worth... (don't tell anyone I told you this)

Cheers,
Navin.

ยทยทยท

Matthew Margolis <mrmargolis@wisc.edu> wrote:

I am working on a ruby cgi script on a host that refuses to give me ssh
access. Therefore I am developing locally and then uploading blindly.

ed wrote:

Matthew Margolis <mrmargolis@wisc.edu> wrote in
news:41F5A084.7010107@wisc.edu:

Anyone care to help me figure this out before I have to cancel my
hosting service and waste time moving the domain?

I'm a newbie to ruby, but try the following:
$stderr = File.open('error.log', 'w+')
$stdout = $stderr

In theory, both stdout and stderr should be redirected to the file.

That's true. But you probably don't want $stdout to go to a file as
that will cause your script to send no data to the user's browser.

One of the problems that could cause the script to work locally but fail
remotely is leaving off the
  print "Content-type: text/html\n\n" # or "text/plain", or
                # whatever
Both of the \n's are important, as that's how the server and browser
determine when the header stops and the content begins. From the error
message you gave, it would appear that that's exactly what the problem
is. Apache executes the script and runs all the way to the end, and,
finding no '\n\n', interprets the body as the header and can't figure
out where the header ends.

Since (iirc) Apache runs on OSX, you could set it up locally and use
that to debug your scripts before uploading them.

Would you mind posting your script?

Eric Anderson wrote:

Matthew Margolis wrote:

Premature end of script headers

The script runs on my mac. I don't know how they have their servers setup(RedHat) so I can't emulate the problem.

This is so obvious I am sure you checked it already, but are you sure the path to the ruby binary is right at the top of the script? You could use the /usr/bin/env ruby trick to ensure that it finds the ruby binary.

Eric

That did the trick. I had the shebang line setup wrong, I guess they didn't tell me the right ruby path. I am so only working on textdrive from now on.

Thank you,
Matthew Margolis