Make your own free website on

"Help Answers" compiled from Ringmasters-l mail list

Web Ring Help


I'm trying to setup a cgi account I need help like whats a PERL and which ones do I need!! Im so confused!!

You'll need to do a lot of research before you're ready to run your own CGI programs.
Unlike HTML (which is pretty simple), even the simplest programming or scripting languages (like Perl) require a lot of time and study.
That said, there are a few questions you can ask yourself and answer which will help you on your way.
1. What do I want my site to accomplish, and are interactive programs the best way to implement that?
2. What *kind* of interaction do I want the user to have? Subscription to updates or newsletter? Calendar? Want ads? File up and downloads? News Updates? A guestbook? Something else?
3. Where can I get that interactivity? Remotely hosted applications? A remote cgi-bin? freeware programs I can host myself? Custom programs?
The first two questions are necessary to determine just what and why you want to run cgi's. Once you have some answers to those, the 3rd question can help you direct your web research in the right directions. YOu might want to start your research at
a great information and programming resource for cgi.
-- Greg (Pel)

(Soft warning: 'nother long post. But if you are new to CGI, it might be useful.)
/bin/ is where you put your .cgi files, and .pl, etc.
It could be also named "cgi-bin" but I believe /bin/ is just the same.
In the UNIX world, which still dominates the Net although Bill Gates is working hard to have it otherwise, the /bin directory, if created at the set-up of a user's account, is typically meant to contain compiled, fully executable files, not CGI scripts. For example, most sites with public, "anonymous" FTP access must have a /bin directory--and one or more small executables in that directory--in order for anonymous log-in to work.
That said, there are two ways, simplistically speaking, that ISPs allow CGI access: either they use a /cgi-bin directory under their control (users can't write information to this directory, but can read and run stuff in there), or they use a server-based utility like cgiwrap that allows users to install and run CGI scripts anywhere within the user's directory structure (generally, this applies to users, like me, who have a virtual domain on an ISP's server). So if his provider is using the latter method and he either is owner-of-record or has write permission to that /bin directory, scripts will run from there.

By far the easiest way to ascertain whether you have the ability to install and run CGI scripts ask your ISP that very question. ;-)
I'm not being facetious, honest. Working with scripts is easy once you get the hang of it, but if you've never done so before it will take a couple of hours of research/study before you can do yourself much good. Only a couple of hours, and well worth it if you can work with Perl or C scripts on your server; but it's wasted time if you can't. 'Course, you might always think of moving your account.
I have vast holes in my knowledge, and the stuff that's supposed hold the rest of that knowledge is rather like a sieve itself. For example, even though I went through a one-week NT course several months ago, I've forgotten most of what was presented and I've never worked with an Internet server on an NT box. But the following miscellany applies to almost all UNIX platforms and applies to a significant portion--if not a majority--of the way Web-presence ISPs operate (as distinguished from dial-in access providers, though they may be one in the same).

Usually, you can run Perl scripts with .pl extensions only in a /cgi-bin directory that is under control of the server's root operator. If you're allowed to install and run your own scripts, they'll probably need to have a .cgi extension. If you are installing a script that consists of more than one .pl script, change all the scripts' extensions and internal references inside the scripts to .cgi just to be on the safe side.
Be careful to upload CGI scripts it text mode, not binary. For example, if you use one of the most popular FTP apps, WS_FTP, don't use the "automatic Detect" or "Binary" transfer mode; specify ASCII text-only.
When you first upload a CGI script, it will have only the default permissions that all your other uploaded files have. Here, you'll probably want to research the CHMOD command. CHMOD can be handled via telnet directly from the command prompt or, again using WS_FTP as an example, may be set via FTP. CGI scripts generally have to be CHMOD 755 in order to operate--owner writeable, but universally readable and executable. Check any instructions that come with CGI scripts you may download. In my experience, the two things that are most likely to cause script failures (assuming the script is properly written in the first place) are incorrect directory references (trying to call or address things in the wrong place) and, ta da, file permission--CHMOD--problems.
Some scripts, for example, will require files or directories to which they write data be CHMOD 777 for full, universal access. Carefully plan where you put these types of files and directories because everybody and his cousin Jim Bob can write to these areas.

The first line of any Perl script needs to look something like this: #!/usr/local/bin/perl (lookit! another /bin directory). If you don't know the precise location from which the Perl compiler should be called, telnet to your host server and, at a command prompt, enter "which perl" without the quotation marks. For future reference, the "which" thingie is handy if you need to find other resources, as well. For example, "which mail" will show you the absolute path to your sendmail engine; "which crontab" will show you where utility lives that allows you to create timed events.
I've never found it necessary, but if a script blows up when named, say, scriptname.cgi, you might try naming it nph-scriptname.cgi, the nph- standing for "non-parsed headers." This has to do with the script's Content Type tag; something you likely will never have to muck with.
The best way to test a script after it's installed and all permissions set is to telnet in and run it from the command line.
Change to the directory that houses the script, then try executing it by typing, "scriptname.cgi -debug" and if you get compilation error messages, they should give you a clue as to where things are going awry. If the script fails to run at all, check the file permissions, then try the nph-rename thing and try running it from your Web browser; you should see any error messages in a "verbose" mode.

If you're running a script that needs server-side includes, most servers require that the associated HTML file be named with an .shtml extension.
Now some potentially helpful sites that deal with the CGI gateway:
(Nice reference site overall)

(My vote for longest URI on the Net)
-- Ed Williams

Great post, Ed - that's as clear a post as I can imagine for an intro, and way better than I could write. Only thing to be aware of is you can't CHMOD with older versions of WS_FTP, just the newer ones. And for reference, the one "free" host I know of that allows you to run your own cgi,, doesn't recognize .shtml for SSI - .html works fine, though - and allows you to mix .pl and .cgi files with impunity. (I mentioned the qmail-inject thing in my first post about CGI).
The .pl vs .cgi issue leads to some funny things - programmers may refer to "" internally, but rename the script program.cgi without changing the internals, so you need to watch out of coder errors, too.
-- Pel provides a free and easy form e-mailing service which can be used on any server.
-- Wesley Mason

Right, they do. In fact, many cgi functions can be "out-hosted", just like onelist does for mailing lists. For a whole suite of things, like Bravenet's, you can also try CGI for Me ( or X-point CGI (
For a general list of things - not compete, but pretty darn good - try the CGI Resource Index, remotely hosted category -
In general, unless you like messing with code or are doing websites professionally, I'd recommend going with remote hosts rather than installing your own scripts. Script conversion can eat a good bit of your time, and unless you understand at least a little bit of Perl you'll be ripping your hair out in notime.
Example - many scripts will send mail to you or a recipient, and almost all of them assume that your host system uses "sendmail" to process outbound SMTP messages. doesn't - it uses something called "qmail" and the message processor that replaces sendmail is "qmail-inject". Now - qmail is a very kewl application with many many good features - but if you don't know that you can't append a parameter "-t" to the program call, your mail won't go anywhere. Since sendmail requires that -t, most scripts embed it either in the variable that stands for the mailer, or in the script itself when the mailer is invoked. Get rid of the "-t" and it works wonderfully - and it took me HOURS of searching around the web to discover what the problem was, and then editing the scripts and retesting them to make sure they now functioned properly.
With a remotely hosted script you won't have that problem (or the others that involve and ...and...and *ARGH***). You won't have as much control of the application, and you may have to put up with advertising banners in the script, but for most people I think it is worth the cost to avoid the headache.
Hope this made some sense,
-- Pel (st_peliel)

My provider won't let me put scripts like the,, etc in their cgi-bin directory. I want these scripts to execute to make my homepage a bit nice and complete!

Unless your provider allows you to execute your own scripts, you may be out of luck. Who is your provider? You might also want to checkout, or for scripts you can run from your home page on their machines.
-- Pel

I'm a bit stuck with my helpdesk, the forms I use aren't send to my e-mail, I know the reason, it's that damned CGI-script, does anybody know a webpage where you can find help on it??

Try the following:
has six sites listed that support calendars , maybe you can find one you like.
-- Adrian King

Back to Main MenuUp to Top of Page

Launched 2-13-98

Copyright 1997/1998 Morgan Smith
All rights reserved. All Images,
downloads and text are ths sole
property of Morgan Smith and cannot be used
without written permission of the
this publisher.