These are not beginners scripts - Read the supplied readme help pages - not perfect but contain plenty of info for a "free-to-use program. If you have next to no knowledge of servers, paths, permissions checking, set-up variables importance, and logical responses to the MANY error possibilities etc, then these scripts are not really suitable for you...
...but good luck any way if you do try.

NOTE: These scripts are created as working programs for webmasters, and not the common "play with and learn" free scripts found on many sites. If you are affronted by any of this, then please use someone else's programs.

Install help from me for my scripts, not installed by us, has been suspended!
"For intermediate-level installation experience" means that if you have only installed a couple of simple scripts on a "wet Saturday afternoon", do not understand absolute paths, relative paths, full URLs and relative URLs, server and user permissions - implications and how to double check them even if you think they are correct, AND cannot read the readme help files - every line before installing, AND cannot use error responses and logic to direct you to the various problem areas your installation could have created, then you do not have what could be classified as intermediate level experience. Don't just blame these or others programs.

• Almost all problems relate back to program usage of cgi sub directories. Many advanced programs use them and files within presenting new requirements that are mostly "server specific" - ie NO programer can tell you how the engineers have installed their Server/CGIWRAP/Perl software and specific idiosyncrasies.
   For instance NOTE the section below as example - "Program called URLs - www.?????".

As perhaps most more complex programs and therefore extended program processes are generally obtained at cost (and therefore rarely experienced by many), the less experienced using dtp-aus.com free-to-use programs often find themselves confronted by "server specific" requirements not otherwise of any real concern when dealing with simpler programs.

dtp-aus.com programs are now downloaded 1600-2000 each week. The install success rate from downloads is very high (we do offer a low cost professional install service for those with no time, knowledge, or desire to install themselves - and the low cost for the time involved and pre/post checking we professionally perform should indicate such is offered only as a service).

Please Report...
If you have tried any of my Perl CGI scripts, please let me know on what type of server you used them and generally how they installed and performed (note FrontPage message below); it would be very much appreciated, but do not use this mail link asking for help - see below.

Bug Reports
For Bug Reports, read the suggestions / fixes below this section FIRST, then e-mail via this form.
These scripts were developed for Perl 5 on an Unix server using Sendmail. Some may work on other systems with few changes IF changes are allowed.
All programs currently use the flock command ( ie not suitable for NT/Windows! ).

MS FrontPage Extensions
If you create your pages AND PUBLISH to a server using the FrontPage extensions, then there is no guarantee that CGI scripts will work (EVEN if the scripts are "properly" FTP installed!). Some Hosting services only supply Perl CGI access OR FrontPage extensions, but not both for this reason. DO NOT use FrontPage to publish scripts (upload). Use a suitable FTP (File Transfer Protocol) program. If you do not know the difference, you should only be installing simple scripts anyway - to get the experience!

PERLTEST.CGI perl CGI script is a simple script for testing your cgi-bin suitability for dtp-aus.com Perl 5 scripts. Just uncompress this .zip file on your local hard drive, check the call command to perl - first line, then FTP upload it (the script, not the .zip file) to your cgi-bin. Set the script permissions to chmod 755 and run the script from your browsers command line. It will send back a simple web page report on your perl version ( file is now supplied with all programs ). Preset the internal URL variable and you can check various Sendmail paths.

Thanks to those of you who do help by reporting back with installation info, and even with donation support - appreciating the many hours of work that go into creating free-to-use and registered scripts plus detailed "readme" support to help you create a better interactive site - All these scripts and copies of them always remain my property via Australian copyright laws, the Berne Convention, and other International treaties - including in USA!.

 
If you want to, you can learn from the following comments and advice:

Many report appreciation for the detailed program readme help files and this page - often reporting they even learn more from them.

Sometimes one has to be "blunt" to help:
Every professional installer and programmer will NOT assume bugs or problems with the program or its config method when difficulties arise especially when proven programs of long standing are involved.

Server set-up VARIES OFTEN and it is the site idiosyncrasies that almost always create problems. When facing problems, assumptions of knowledge from prior simple installations is therefore of little use to anyone except to perhaps underpin a raging ego!

These programs are offered to help people create better interactive web sites and often it takes little to view some other programs code to see a lack of internal security, efficient program devices and so forth. These programs are versatile and interfaced with attractive admin pages etc too where applicable because users prefer the extra development...
but even that can also add to the complexity of installation.

Remote help can only go so far and many people do not want to hear that they are inexperienced installers. So to stop our bashing our heads against the wall further, read the following and understand why... beginners installing help is not supported - except for actual program usage - and indeed what experience will teach you if you let it with an open humble mind!

All programs listed here at dtp-aus.com are highlighted "for intermediate level installation experience". ie If you are an experienced installer of perhaps mySQL databases etc and associated programming, and have "root" server (not just site) admin access then you probably have advanced level experience.
All programs here are standard Unix server programs requiring Perl 5.00404+ access and "Sendmail".

Some simple questions:
• do you really know what the "Auto" function in your FTP program is about?
• do you manually upload ALL files as ASCII with only images as BINARY?
• do you really understand how to use the much simpler "relative" paths?
• do you know the absolute path to your "cgi-bin" directory?
• do you know the absolute path to your "html docs root" directory?
• do you know your path to "Sendmail"?
• do you know some sites allow cgi-bin R/W sub dirs @ 666, or 766, or ONLY 777?
• do you know some sites disable program created cgi-bin sub dirs - manual only?
• do you refresh your FTP program listing before re-checking permission values?
• are you silly enough to upload a win.zip file and expand it via Telnet?
• do you understand the MANY possibilities from this simple server error?
"The server encountered an internal error or misconfiguration and was unable to complete your request"
• do you realise that many servers allow a manually created (defaults) CGI-BIN SUB DIRECTORY to "create, read and write" although permissions indicate they do not (and remain secure), yet others will only do so with chmod 777?
• do you realise that many servers allow a manually created HTMLDocs SUB DIRECTORY to "create, read and write" HTML files and upload to/access image files although permissions indicate they do not, yet others will only do so with dir chmod 777?
• do you know that to run a CGI program from an HTMLDocs directory is possible on some servers BUT that also saving data to that or a SUB directory leaves your data/config/private info wide open to security abuse - see "CGI-BINs" below.
• do you know latest Linux versions hide hidden file listings via FTP creating confusion trying to delete an apparently empty directory - ie containing .htaccess / .htpasswrd files.

Perl
Using a perl path in one program does NOT mean the same path will work for every program - especially if auxilliary sub dir files and CGIWRAP is involved. These programs require perl 5 (.004+ preferred). Most servers have at least four or five perl paths and a few still have a version 4 as default (v5.001 contained bugs!)! We cannot tell you which is which on your server.....
Via Telnet at the root prompt try "whereis perl" and then "which perl" to view some often instructional results!....or try our simple "testbin.cgi" program.

Site Structure
Cgi-bin and HTML Docs directory structures differ between servers. We cannot tell you what they are. Most sites contain the cgi-bin as a sub dir off the site htmldocs root, others have the cgi-bin below the site htmldocs root. If you do not yet know the difference between absolute and relative paths and URLs we cannot help you (relate them to same for URLs in html web pages). If you do not yet know the real differences between a cgi-bin and an html docs directory we cannot help you.

There are some servers set up with DIFFERENT absolute paths to the cgi-bin AND the html docs (html site) root directory!

The "makedir.cgi" utilities will work on most standard? unix servers (if you know the required chmod values), and many feedback comments report the ease and speed of installation after use - especially hepfull with many auxilliary files). But some sites will only allow manual directory restructuring. Also, the advised default programs set up using simpler "relative" paths work on most but again cannot be guaranteed (a few CGIWRAP installations become "lost" with relative auxilliary file paths!!!)....
    and if you change our advised structure then it is up to you to understand it!

Permissions
Also realise that servers OFTEN (emphasised) have non-standard directory and file permission requirements (chmod); it is up to you to find that out from your sites manuals or hosts help pages. No programmer can tell you exactly what they are; except to make common suggestions. (even some sites have been found when installing by us to require "??.cgi" permissions of 701 instead of 755 - very rare but the message here is obvious)

Claytons CGI-BINs - a cgi-bin when you don't use a cgi-bin!!!!
Many webmasters find that their site allows the creation of a directory of that name other than a true server created/protected cgi-bin that allows perl cgi programs to run apparently normaly. oooops! - also see "simple questions" above and "CGI-BINs" below.

Most often these "cgi-bins" or what ever one calls them are NOT server created and therefore are NOT server protected. The incorporation of a default html page "index.htm" or "default.htm" or whatever may stop browsers from viewing your contents, BUT...
what about hackers and rogue search engine robots that can access the contents and list all files?? Once URLs are obtained all private data and "trusting user" e-mail lists etc are readily available. So think twice if you do think that creating an external cgi directory looks better or tidier or just prettier! in your FTP program!!!

FTP
If you use the "Auto" function rather than the manual option when uploading files via an FTP program, then sorry, you are not very experienced! Programs with auxiliary files will often use different extensions from one program to the next, mostly for good reason. Unless the auto function is painstakingly set up each time then you are bound to run into problems.... do each dir / file manually.

• An auxilliary file with an extension of ".pl" is not necessarily an executeable file! If not it just needs "read", and sometimes, "write" permissions.

• To consider your inability to install a program with different requirements to other simpler ones you have installed as "a bug in the program" means that you will never appreciate the possible complexities of the various servers/programs (thousands of others do OK!).

• Like most suppliers of programs we surprisingly cannot spend all day just waiting for and answering problems faced by those that want to install themselves from the many downloads every day. Program usage queries are readily answered where possible but we cannot teach you the above topic variations - that comes from investigation and experience.

• To not read the readme help pages supplied in detail and not check with this page means that you probably already know too much and should not be having problems!

So like all well trained tradesmen and technicians DO NOT ASSUME ANYTHING that you did; we all make simple mistakes that can sometimes be difficult to trace with out experience and an open mind. ASCII / Binary uploading requirements and Directory/File permissions are the primary reasons for problems, followed by incorrect config paths/URLs - ie a "program" error notice indicating it cannot Read a file could be a wrong path OR wrong dir/file permissions.... and again, do not assume program faults when thousands over two years have had few problems.

This page is updated with any known major fixes or suggestions, and all programs are regularly updated /checked. We do not create and forget as is the case with many program suppliers, because as with the dtp-aus.com tutorials the aim is simple - to help other web masters with fairdinkum programs; and the time involved in doing that can never be fully compensated.

Lastly - RTBM!

As it should be, most programs have TWO passwords.

• All Ron Woolley's admin supported programs have ALWAYS required double (two) passwords for access and editing. One created manually when preparing the config file set-up. The other created / encrypted when first viewing the admin pages. (if you do not appreciate why, find it bothersome to use two, and don't care that you may often allow other sites to discover your single passwords to various admin applications editing... we even discover same occassionally via our own version of LogCount / LogLook... then please do not complain!). 2001... Some public programmers? are only just recently offering same as if some newly discovered option advantage!!

CGI-BINs
When installing around the world it is alarming to find so many incorrectly setup cgi-bins (or equivalent - ie cgi-local or whatever) when performing our server/site interrogation. The primary need for a cgi-bin is not only to allow the execution of programs (for Perl it is only ".cgi" and/or ".pl" files) BUT block access to auxiliary files... AND why few programs are suitable for installing in any other htmldocs directory unless all aux files and saved data are placed in the cgi-bin or its sub directoriess.

The number of sites around as above is quite prolific (and often programmers of publicly available programs recommending bad installation suggestions allowing htmldocs dir installs).

CGI-BIN AND HTMLDOCS directories
• Just placing an "index.cgi" or "index.html" file in such directories IS NO DEFENCE!!... just like shutting the gate but not building the fence either side of it.
• Even worse is a situation where the Host company responds to same from a clients query after our suggestion regarding their cgi-bin with "just add 'index.html' files in those directories" - as has happened too many times.

...... your program paths, server paths, setup data, saved password lists, email address lists, etc could then ALL be left wide open to rogue indexing search robots and worse still - robot programs sent by mischief makers.

TEST
In short there is one simple test you can apply to your cgi-bin non executable files OR same where cgi has been installed in htmldocs directories.... try
   http://www.yourdomain/cgi-bin/file.name
and
   http://www.yourdomain/cgi-bin/cgiSUBdir/file.name
from your browsers command line ( NOT just **http://www.yourdomain/cgi-bin/ ).

**The latter, if an "Access Forbidden" error is displayed, can be generated by a directory listing block YET NOT by what the server is told to restrict access to - two separate OS S/W issues.

IF your browser then attempts to show the contents of the file OR opens the "Save As" option window, without displaying an "Access Forbidden" error you are in big trouble. Contact the host technicians and request the cgi-bin be repaired (most likely all their hosted sites on the same server are likewise) OR run quickly to a decent host even if you have paid in advance!!!! The only fix for cgi and saved data in html docs directories is to move the install into a secure cgi-bin.

E-Lists v2.2 June 6th 2001
A problem with e-mail address case matching has been fixed affecting some list members when UN-subscribing or perhaps attempting mail format changes. Download v2.2 again and just replace the files displayed with the date 06/06/2001. This is not a problem with v2.3.

NEW Sendmail E-Mail Header Format
Early VizBook 2, ListMerge 2, ennyForms 2.07 only....
Changes being made to e-mail sections of programs now include angle brackets around the address fields enabling the inclusion of the name component.
• This only affects a very few servers where Sendmail/MailServer is set up to follow "STRICT" original rfc821 SMTP protocol.
• Generally this is not a problem. However if your mail is not sent to visitors (auto-response) or ListMerge mailouts, check the following....
***Simply reverse the order of the fields as follows:
    print MAIL "To: <addressField> nameField\n";
    print MAIL "From: <addressField> nameField\n";
AS:
    print MAIL "To: nameField <addressField>\n";
    print MAIL "From: nameField <addressField>\n";

LogCount Utilities
For the first couple of weeks after v3.8 was posted (March 1 2000) the two changed SSI "exec" link utilities "linkcount.cgi" and "linkname.cgi" were not included in the .zip. V3.8 included new config variable names that required a file path change in those programs. It is simple to fix. Find "$lnk_url" in each script and change to "$log_path$lnks_name".... that's it! - or get the latest...
     the .zip now includes the correct files thanks to Keith Kneisley feedback- 15/03/2000.

.CGI or .PL ?
There are Unix type servers that will only accept one or the other program extension (most commonly both - applicable to the actual called program file only).

But then there are a few servers that will run a ???.cgi program, but not accept data from a forms "POST" method resulting in very strange and uninformative results depending on program logic (possibly through cgiwrap not sending the environment array or similar).
   If so, try changing the program ".cgi" extension to ".pl".

Editing
Did you check that a simple ( " or ' or ; ) was not accidentally deleted when editing the configuration variables? Was the back slash ( \ ) left out of the variable's value when changing the webmasters e-mail address variable strings? ie = "woopsy\@doosey.net";
BUT NOTE: program variables with a value enclosed in single quotes '....' do NOT need the \@ bachslash!

Server Error
Here are the most common possabilities with this server error. It may not teach you much but sure as hell shows how much we can do wrong before blaming a program!
error: "The server encountered an internal error or misconfiguration and was unable to complete your request"

directory / file permissions (any file or dir - you have to check them all).
directory / file paths (sometimes reported as "file not found").
binary upload instead of ASCII (don't use an FTP program "Auto" file type function).
wrong perl path (a path may work for some programs yet not be to v5+ or server default).
wrong path to "Sendmail" (if the program is sending mail).
preferably use a path to perl 500404 or later - and higher the "00?" value the better the chance a final stable release is used.

The "@" character
Perl often requires that non alphanumeric characters in "strings" are preceded with a backslash. The most important of these to observe for Perl 5 is the "@" character used in e-mail addresses.

As some of my programs take in auxillary files as "require" files (placed in complied memory with the program), the exclusion of the backslash before the "@" can create a server error because the compiler reads it as an out-of-context array definition.

An example of this would be the header and footer files one can edit for personalising the top and bottom of the earlier versions of the VizBook book page - ie an e-mail address in the html code should look like you\@adomain.name. Only make this change if problems arrise and you have included the "@" character somewhere ....sometimes it is allowed because of the way the texts are used... ie the program expects and checks for it.
A helpfull tell-tale is when the imported data (or a section of it) is wrapped by full quotes ["..."] and begins with a [$] named variable!
NOTE literal values enclosed in single quotes '....' containing the "@" are not a problem!

VizBook v2.0a May 2000; received minor internal improvements a few days after posting.

Also UPGRADES NOTE: VizBook v2.0 will NOT allow editing of older version entries. THIS IS NOT A BUG but a result of necessary changes and addition of an ID file for this and future versions.

Also see "New Sendmail E-Mail Format" above.

Program called URLs - www.????? - not the @referer array below
On most servers it is possible to call simple perl cgi scripts and htmldocs pages with and without the "www" prefix to config URLs. Yet on a few encountered, once the program internally accesses auxiliary files in cgi sub dirs the environment string is lost.

If all IS DOUBLE CHECKED for permissions/paths/ASCII upload etc and confusion still reigns, make sure all config URLs contain the "www" prefix (it is believed to be a cgiwrap set-up thing!).

Some servers do not allow reading and writing of directories/files using chmod 766 (r+w). For the support file subdirectories and text format files in them, chmod 777 can be tried as a last resort but also required on some servers.

May 2000: The FILES IN cgi sub dirs of all programs should first be attempted with chmod 666. This note will be addressed as program / readme pages are upgraded - eventually some files will be recommended for 664.

The following is no longer applicable to recent versions ( late 1998/early 1999 only ) but will remain for earlier version users! ...upgrade of all programs is strongly recommended.
( The readme.htm pages have been updated to direct you to simple changes also needed in the scripts and some 'require' files if you do change 766 to 777 )

LogCount v3.5e - SSI fix
Version 3.5"e" contained a bug preventing SSI image display. This has been fixed - v3.5"g".

LogCount v3.5 - @referers array
For the first couple of days after the release of v3.5 there was a minor error in the @referers array in the config file. The default line supplied before set-up should be:
@referers = ('www.yourdomain.nme','yourdomain.nme',);

@refererers and "bad referrer" errors - "remote access denied"

This ALSO blocks access via a browsers command line AND a local pc copy of a page containing the links - even yours!

The number of persons having problems with this concept because other simple lacking programs installed do not cause the problem is amazing.

IF a program is set to use referrer checking and you disable it just because you find it bothersome not being able to use the browser command line during testing and after, then quite frankly you are an idiot! No need to try and teach a webmaster all the implications but you have been warned.

Even password access forms can be more easily cracked via remote automation if disabled!!!

NOTE: The security of the @referers array will stop you from calling a script from the command line. Use a webmasters secure page for administration links and calling programs and admin scripts - ie ONLY a link ON your site will be accepted... not even a page copy on your pc.

The @referers array in the "????.set" or "????.pl" config files (there are two types in upgrade transition), and the readme.htm direct you to change the default values to ones suitable for your domain name. THESE ARE NOT paths, but domain names and each is a reference that the scripts appends to http(s)://. This is a security feature. Some programmers even allow other characters before the "www" when code checking referrers. There are plenty of rogue PC programs that can get around referrer checking if checking is so written! Checking should be explicit - ie "https?://RefferArray_item'.

Many sites can be called via 'www.yourdomain.name' AND just 'yourdomain.name' (without the www), so this array checks to see that calls to the scripts are indeed made from pages loaded from your site, and not remote copies that can be used to spam forms and affiliate links or record incorrect counts.

COMPLAINTS
Occasionally visitors might complain they can't download or whatever because of the checking. DO NOT weaken and disable checking just for a few. Amongst the few will possibly be someone who is fully aware of the reason!!! Source traces can be hidden from the server AND THEY CANNOT BE TRUSTED. Just tell the complainant to try another ISP ...IF you want to respond at all!

Invalid entries to this array do not matter as long at least one of the two as above is correct (if pointing other domains to your site include them with and without the www too).

Referrers are notified to the server by the browser - if the viewed page is not direct from your site (a copy or browser command line direct cgi call) then the cgi program will rightly complain.

A few paranoid? servers have cgi scripts set up under cgi wraps etc that report garbled and/or inconsistent referrer paths. These are becoming rare. If all is double checked and the "bad referrer" error continues to stop you using the scripts correctly through on-site pages, look for the following near the top of the scripts under the copyright etc notices:
"&ref_ok;" or "&check_ref ;" or "&is_referer_ok;".

Try the scripts with a hash sign ( # ) placed at the beginning of these lines ie:
# &ref_ok; BUT DO head the warnings above.

That will disable referrer checking; also helpful temporarily if inexperienced and testing the initial install - in other words reset it later.

DO NOT create your own CGI-BIN, or use another name just because it looks better or neater or even sounds better! - especially if you are not FULLY aware of the idiosyncrasies of your Server. If the site is supplied with a server setup cgi-bin then use it!!

DO NOT use a sub directory of the CGI-BIN, or any other directory, to place the actual scripts in unless you know that it will have full server protection and script compiling permissions (should be OK if server setup of cgi-bin is supplied with site).

DO NOT use a directory name starting with the underscore ( _ ) character if there are MS FrontPage extensions installed on the server (installed by the Host).

Note: You can use FrontPage to create sites on your own computer, but do not publish them with FP if you intend using perl cgi scripts on a Unix server. Use FTP ONLY for scripts / progarm files.
If you do want to use FP then DO NOT include the perl cgi-bin structure in the FrontPage site (on your pc). Create it well away and FTP program upload scripts separately! IE:....the directory "cgi-bin" can be included in the FP site on your PC for link reference but do not place perl cgi scripts in it

.ZIP Note: All zip files are created on a 'Wintel' machine. If uncompressed files are not correctly uploaded by FTP AFTER expanding locally on your PC, the hidden line endings in all files will not be converted to Unix, usually breaking a script with a 500 error. (our programs are developed in both a Windows IDE/server and Unix environment - but are not NT compatible!)

Note: dtp-aus.com programs are developed on Perl 5.004 as of June 2000 and before then just 5.003 for compatibility reasons re most servers. We would like to but do not use the latest Perl - most hosts understandably do not upgrade when ever a new version comes out.

Note: If you obtained any of these scripts via sources other than directly from this site, you have obtained and are using them illegally - too many problems are created by so called friends of users (know-all idiots!), and second rate installers, and plagiarists... if you think that is "attitude" then you do not have to deal with such cretins.
Don't like it? Then use some body else's scripts! - compensation can be lucrative.... Australian and International copyright; as per Berne convention and other treaties - USA included! registration NOT required.

makedir.cgi

It is possible to successfully run the supplied utility "makedir.cgi" on some servers without setting the correct directory permissions first...
BUT THEN FIND that all FTP access to, and deleting of, the new directories is refused!!
DO NOT PANIC, just change the directory chmod value in the program and run again - this will reset the chmod values ( at the program level which set them in the first place ) and all will be OK.
  easiest described in these cases is that the server does not like the value first used and so safely locks up all access.

If unsure of required chmod values and things do not work, change the DIR chmod to 777 (and 0777 where applicable) and try again. Some servers do not like programs creating directories - create by hand and run again to create the default files.

NOTE: We always use makedir.cgi because it does/can indicate certain requirements of a servers set-up - not just to easily create correct file names.

ennyForms name change from anyForm (March 12 '99).

FTP Permissions / CHMOD - basics
When setting the permissions for files and directories, it can take a while for beginners to get used to the setting protocols used. There are three common methods used in FTP programs. Words or characters, and CHMOD values.

Words and characters are:
Read, Write and Execute, or a series of characters and dashes; r,w,x,- (hyphens).

Each represents a fixed number, and with chmod we need to know how to set each of the group of three values by totalling the read and/or write and/or execute numbers accordingly.

CHMOD:
uses a numeric system, 0 to 7.

And there is also a group of three used for each method. They are for - the system, user group, and the world; world being any and every body (sometimes chmod values begin with a fourth number, 0, and if so should always remain as 0 - ie 0755).

So the following list should suffice for cross referencing when one method is stipulated by the author and yet only another is available in your FTP program etc:

Read = r = a value of 4
Write = w = a value of 2
Execute = x = a value of 1
hyphen "-" = 0

Unix servers account for approximately 50% of ALL server configurations.