PDA

View Full Version : need an example of simple perl script + html



smashcon
03-14-2004, 04:14 AM
i can't get a simple 'hello' world script to work. i've done the following:
1) placed the script in the cgi-bin
2) script's name is hello.pl
3) its mode is 755
4) script contents bellow
5) i've tried running it by going to it directly (www.mydomain.com/cgi-bin/hello.pl) and got a 500 error.
6) i've tried to use SSI but no include was created.
7) i've tried changing the script's extention to cgi.

the "hello.pl" script:
#!/bin/perl
print "&lt;HTML><BODY>Perl CGI Hello World!</BODY>&lt;/HTML>";

as you can probably understand, i have no experience with cgi scripts - only with perl and html.

any pointer to what i'm doing wrong, or any example that anyone can show me will be very much appreciated!

thanks,
uri.

FZ
03-14-2004, 05:28 AM
I've run into this problem a couple of times myself. The fix is annoyingly simple:


#!/bin/perl
print "Content-type&#58; text/html\n\n";
print "&lt;HTML>Hello from Perl&lt;/HTML>";

All you need to add is line number 2, which is stating (to either the server or the browser, I'm not sure) that the output you are generating (i.e. your next print statement) is HTML and should be interpreted as such.

Good luck with the Perl coding! Personally, I prefer PHP - it is so much easier, and much more forgiving. Plus, 99% of the time, it generates an error that actually tells you exactly where you have gone wrong, instead of just spitting out an unfriendly error 500.

wildjokerdesign
03-14-2004, 06:01 AM
Well there is what Fayez mentioned and you have the path to perl set wrong if you are woking on a WestHost account.
/usr/bin/perl

FZ
03-14-2004, 06:32 AM
/bin/perl works too ;)

Both /bin/perl and /usr/bin/perl are actually symlinks to /usr/local/perl/bin/perl...

Update: I forgot to mention that you might actually be able to pick up something useful (debugging-wise) if you take a look at /var/log/httpd/error_log.

wildjokerdesign
03-14-2004, 07:19 AM
Opps :oops: my mistake. Was thinking new accounts only allowed the one path and did not even check it. Most likely you are right it is simply the Content Type. I always make that mistake.

Also something to mention is to make sure that you have uploaded the file in text and not bianary mode. My FTP tends to flip back to bianary mode if I do not watch it. :)

FZ
03-14-2004, 07:36 AM
I guess they have created so many symlinks/alternate paths to make sure that people's scripts don't break (i.e. standard paths, paths that were used on 1.0, and so on). It's really messy (i.e. the number of files, understanding where the actual file is, etc.) but it's better not to mess with it in any case.

Good point bringing up the Binary vs. ASCII mode as well, I remember that giving me problems when I was first getting in to Perl as well (i.e. Perl scripts have to be uploaded in ASCII/text mode).

smashcon
03-14-2004, 03:42 PM
Thanks guys!
I'm affraid I've tried everything you've mentioned, but still get the same result.
I've taken a look at the logfile that you've mentioned and here's what it says:
(2)No such file or directory: exec of /var/www/cgi-bin/hello.pl failed
[client 62.90.164.194] Premature end of script headers: /var/www/cgi-bin/hello.pl

any other ideas?

FZ
03-14-2004, 04:48 PM
Well, the "Premature end of script headers" is definitely the content-type problem I pointed out, so maybe you did not "implement" it correctly: copy and paste the code I quoted above exactly as is and see if that works?

Update: coming back to the "No such file or directory: exec of /var/www/cgi-bin/hello.pl failed", after having looked it up, here are a few possible explanations (I've simplifed them):

1. You are not uploading in ASCII/text mode (i.e. you are uploading in Binary mode). You must upload in ASCII/text mode, or use pico via an SSH session to create your file.
2. There is a misconfiguration issue in Apache, but this obviously does not apply in this case.
3. The #!... is not the very first line in the file: it has to be the first line. Also, I think you should remove any excess blank lines (or whitespace) you may have added (e.g. tabs) as I seem to recall some quirkiness with these when I was into Perl scripting.

If, after the above, you still can't get it working, you could e-mail me your file exactly as it is, and I'll see if it runs on my account.

jalal
03-15-2004, 09:43 AM
Maybe a silly question, but are you sure Perl is installed?

"No such file or directory" could mean it didn't find the script, but it seems it did as there was a "premature end of file headers".
It can also mean the script failed to run correctly, which can be because a) there is no perl, b) the path to Perl is wrong, c) the script is not marked as executable or d) some other error that stops the script from running correctly.

SJP
03-16-2004, 03:31 PM
Definitely make sure the executable bit is set (#chmod 0755 filename.pl). Also make sure the program is syntatically correct (perl -c filename.pl).

SJP

smashcon
03-23-2004, 02:31 AM
Hi all,

I had sent the script to Fayez and he tried it out on his account - and it worked!

It took me a long time to figure it out. After trying everything with no luck - I turned to westhost's tech team. Although reluctant to support CGI, I told them that the same script with the same settings works on another user's account (referring to Fayez). Well, they eventually got back to me and told me they fixed the problem - and indeed the script suddenly works.

However, they didn't specify what they did to fix this. At first I thought it was some server setting that doesn't concern me, but then I discovered that when I modified the script, it stopped working - even if I just changed the output string. Anyway, eventually I found out that in order for the script to work, instead of a normal newline character at the end of each line, it needs to have just a x0A character (newline is x0D x0A). However, all of my editors terminate a line with a complete newline set. In any case, though, if the same script ran on your account then it had newline sets rather than just the x0A character!

Well, does anyone have a clue as to what I should do?

Oh, and another brief question: does anyone know if there's a way to use SSI on westhost?

Thanks again!
Uri.

wildjokerdesign
03-23-2004, 04:28 AM
Not sure what you can do about the new line thing but hopefully tech or someone else will have an answer there. I am not even sure how to check a script to see the difference I know with my text editor I have the option to save it as a window or unix type file. It is called Editeur and I got it at www.studioware.com Have you tried to make your edits on the script via the File Manager in the Site Manger. Perhaps it would not add the extra charecters.

The SSI thing is an easy answer yes you can use it just include the call in your html page. You may have to use a .shtml extension for the page although on my account it can even be used with pages that do not carry the .shtml extension. Not sure if that was set by default or not. My accounts where some of the first to migrate and and as you can tell by your problem it seems not all accounts are the same for sure.

torrin
03-23-2004, 07:42 AM
However, they didn't specify what they did to fix this. At first I thought it was some server setting that doesn't concern me, but then I discovered that when I modified the script, it stopped working - even if I just changed the output string. Anyway, eventually I found out that in order for the script to work, instead of a normal newline character at the end of each line, it needs to have just a x0A character (newline is x0D x0A). However, all of my editors terminate a line with a complete newline set. In any case, though, if the same script ran on your account then it had newline sets rather than just the x0A character!

Well, does anyone have a clue as to what I should do?

Let me guess, you're working with windows editors right?

You can translate by using dos2unix or vim. Problem though. I just tried dos2unix on my westhost 1.0 account and can't get it to work correctly. Maybe it works right on 2.0. The syntax for dos2unix should be.


dos2unix inputfile outputfile

As for vim it's not install on 2.0 by default, but you can use it on windows. Let me know if you want to try this route.

jalal
03-23-2004, 09:04 AM
As for vim it's not install on 2.0 by default, but you can use it on windows.

Actually, I discovered it is installed. Just renamed to 'vi'. But 'vi --version' gives me:
VIM - Vi IMproved 6.1

:)

torrin
03-23-2004, 09:40 AM
In that case, you can open the file in vi and type . . .


&#58;set fileformat=unix

and then save it and quit with . . .


&#58;wq

wildjokerdesign
03-23-2004, 11:58 AM
So for others that may have a similiar problem and not be sure if it is because the file format is dos instead of unix is there a good way to check this via SSH or even FTP for those who do not use SSH?

WestHost - MMellor
03-26-2004, 04:10 PM
-WildJoker
Usually you can open it up using pico. If you see a whole bunch of ^M or all the lines are on one really big line, then the file format is wrong. Hope this helps.

wildjokerdesign
03-26-2004, 07:36 PM
Thanks Michael that is good to know.

SJP
03-27-2004, 04:17 AM
My biggest gripe with VIM under Mandrake 9 at least is that it "tries" to insist I put certain perl statements or what have you in particular columns or ident in predetermined ways. I tried using the option to make it behave like the unimproved version (my favorite), but not quite. :-( And it'd sure be nice if they'd fix the freaking copy and paste functionality. Really f__ks up the formatting. I remember when I first got my Linux reading articles by other Linux affectionados wondering why anyone would want to use anything else (like windows). Well after doing battle with them both I could come up with some pretty good arguing points. A nice feature though is that VIM will tell you right off the bat if your document is DOS or UNIX format (bottom of screen).

SJP

torrin
03-27-2004, 10:39 AM
My biggest gripe with VIM under Mandrake 9 at least is that it "tries" to insist I put certain perl statements or what have you in particular columns or ident in predetermined ways. I tried using the option to make it behave like the unimproved version (my favorite), but not quite. :-( And it'd sure be nice if they'd fix the freaking copy and paste functionality. Really f__ks up the formatting.


&#58;help filetype
&#58;help autoindent

will help you with the indent problems. More specifically . . .


&#58;filetype off
&#58;filetype plugin off
&#58;filetype indent off
&#58;set noautoindent

will turn off that behavior. As for the copy paste, I don't know what the problem is.

In case you're wondering that stuff is set up in /usr/share/vim/vimrc. My wife uses Mandrake Linux so I get to do all the trouble shooting when something goes wrong.

You say you like running in compatible mode? Try this . . .

vim -u NONE -U NONE

SJP
03-27-2004, 02:09 PM
thanks for the tip Torrin. You got any good suggestions on an internal modem that would work under both Linux and Windows? I had a 3m905C, but it died.

SJP

torrin
03-27-2004, 09:16 PM
Sorry we haven't used modems for several years in this household.

You might try the hardware howto from the linux documentation project . . .
http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Hardware-HOWTO.html#MODEMS

SJP
03-27-2004, 10:16 PM
http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Hardware-HOWTO.html#MODEMS

I've been over that and it's a dead-end. Oh well, I'll continue to use Windows for transferring files, SSH, and what not.

SJP

mananalu
09-07-2009, 01:10 PM
#!/usr/local/bin/perl
print "Content-type: text/html\n\n";
print "&lt;HTML>Hello from Perl&lt;/HTML>";

On my account this worked either as *.cgi or *.pl file.