Ruby?

software development

#1

I’ve recently learned Ruby, and was thinking about converting my PHP to it, but I don’t know the status of Ruby CGI stuff at Dreamhost. Is it supported? What restrictions? Thank you.


#2

Hi br14n -

I’m not sure, though it’s a good question. I don’t recall having ever being asked if we support it, so I’m going to give a tentative ‘no’ on that.

That’s not to say that we couldn’t support it in the future, though.

I’m going to ask around, and see if I can find anyone who knows more…

  • Jeff @ DreamHost
  • DH Discussion Forum Admin

#3

Thanks for checking it out. I’d very much like for it to be available, since it’s wonderfully easy in which to code and seems to have pretty mature MySQL/CGI/sessions/etc support.

Oh, ruby seems to be on ganymede. It’s 1.4.someodd, and current Ruby is 1.6.7, I think. Thanks again.


#4

Hi br14n -

Yep, I’ve heard some good things about Ruby. I’ll have to check it out for myself, and see if we can improve our support. If there’s a current Debian package for it then it will probably be fairly easy to support (with recent versions, no less).

I’ll see what I can do. :>

  • Jeff @ DreamHost
  • DH Discussion Forum Admin

#5

Ruby should be part of the main Debian installation these days, so whatever version of Debian is on the user’s server should be the latest /stable/ release.

Cheers.

  • wil

#6

Hrm … According to this page, the latest version is 1.6.7. It’s possible that woody has it, but I wouldn’t be the one to know. Will?

http://www.ruby-lang.org/en/

I notice that there is an O’Reilly book on it. That being the case, it’s significantly more likely that we’d be interested in it. :>

  • Jeff @ DreamHost
  • DH Discussion Forum Admin

#7

Yes, but the latest stable release for the version of Debian on the server might be severly different. You won’t find KDE 3 in any Debian release – not even unstable Debian the last time I looked.

Remember Apache 1.2.x is still being shipped with Sarge, and Dreamhost are still sticking with stable Woody (thankfully – stable is good for any production server).

Debian are actually quite slow to update their packages I’ve found. They favour absolutely solid working solutions to cutting edge features which suits a webhost IMO. If you want cutting edge features, then go for the dedicated hosting option … :wink:

  • wil

#8

Excellent. I hope to see ruby 1.6.7 on ganymede sometime if the details can be worked out. I tried doing a few simple ‘hello world’ type ruby CGI tests, but wasn’t able to get one going. My test.cgi starts with #!/usr/bin/env /usr/bin/ruby and ./test.cgi prints intelligible stuff as expected, but I get ‘internal server error’ when trying to see the output via a browser. Shrug.


#9

Problem with outputting the correct headers, maybe?

  • wil

#10

I hope this HTML doesn’t mess anything up.

test.cgi starts with #!/usr/bin/env /usr/bin/ruby.

./test.cgi
(offline mode: enter name=value pairs on standard input)
arg=hi
Content-Type: text/html
Content-Length: 302

This Is a Test

A Form:


Looks plausible to me, but it doesn’t work from the web.

“Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.”


#11

HTTP 500 Internal Server Error messages are always going to be vague. To find out what the real problem is, check the Apache error.log for the domain in which the the script is running.

For example, I forgot to upload a script first and got the 404 error, well in error.log it appears as:

[Mon Dec 16 20:51:54 2002] [error] [client 69.x.x.x] script not found or unable to stat: /home/username/domain/test.cgi


#12

Ah, checking error log was a good idea. Sorry I didn’t do that earlier. The problem is ‘premature end of script headers’. My test Ruby CGI program uses the Ruby CGI object, which knows how to produce headers, and it does so on the command line. I think the problem may have to do with the fact that, on the command line, I have to enter some parameters like hi=yo&yo=hi and so forth followed by ctrl-d in order to get the output. I’m trying to track down how it tells whether it’s in online or offline mode.


#13

If it’s anything like perl, you would need to enter the parameters in the following form:

name1=value1
name2=value2
name3=value3

  • Jeff @ DreamHost
  • DH Discussion Forum Admin

#14

Don’t you have a problem when executing it as CGI though? If you’re getting premature end of headers, then it means your script is messing up the output when Apache runs it, which is a different situation than running it from the command line. It’s possible that something is sending an error message only when run as CGI.

It appears that would be a run-time error since your script works just fine from the command line. In that situation, you would need to get ruby to make sure the very first output is a valid HTTP header so that whatever error message or bad output is sent to the browser as part of the body. See if Ruby has a BEGIN { } clause that executes at compile time. For example in Perl you would do:

[code]#!/usr/local/bin/perl

use CGI;

BEGIN {

run this block at compile time

print “Content-Type: text/plain\n\n”;
}

my $CGI = new CGI;
print $CGI->header, $CGI->start_html, $CGI->h2(‘Hello World’), $CGI->end_html;
exit;
[/code]


#15

Hmm. I simplified my code.

lwlca10:09pmganymede:~/creativeartworks.cc$ cat test.cgi
#!/usr/bin/ruby
print "Content-Type: text/plain\n\n"
print 'hi’
lwlca10:09pmganymede:~/creativeartworks.cc$ ./test.cgi
Content-Type: text/plain

hi lwlca10:09pmganymede:~/creativeartworks.cc$

Newline added after the for the purpose of readability. Unfortunately, apache still reports ‘premature end of script headers’. Did I screw up? Thanks.


#16

The following simple Ruby example CGI script works fine for me. Check that you print newlines correctly, note \r\n not \n\n. Are you coming from a Perl background? :slight_smile:

[code]#!/usr/bin/env ruby

print "Content-type: text/html\r\n\r\n"
print “Hello World!\r\n”
[/code]- wil


#17

Well only other thing I could thing of is permissions or an Apache configuration error somehow regarding files ending with .cgi (perhaps its trying to do something else for files with that extension?).


#18

No, I don’t think so. It looks like it’s to do with how you are outputting headers. Look at the example (tested and working) code I posted above.

  • wil

#19

I understand what you mean, but on my domain, on my machine (vega), it doesn’t make any difference whether I use “\n” or “\r\n” for a newline. I don’t get an 500 error at all. There has to be something different with the configuration of ruby, Apache or both on his machine. Geez, if even a script with two just print statements still gets a 500 error when run as CGI, and the problem is premature end of headers, there is something inserting some type of output before the first print statement is run. This unexpected output could come from Apache or most likely ruby in the form of an error message. Perhaps Apache doesn’t like executing .cgi files as CGI /w ruby on his machine.

I think that is unlikely. Perhaps it is a permissions problem, and he is uploading the script and running it from the command line as a different user than Apache is actually trying to execute it? Maybe he didn’t chmod it to exactly 0755 ?


#20

Thanks a lot, stuff’s working. I think I was printing slightly wrong headers and, more importantly, had incorrect permissions. I fixed stuff and have stuff I can really work with now. Really appreciate the help!
brian.