create new tag
, view all tags
This is an archive of older information and tips - see TWikiOnWindows and TWikiOn for pointers to current installation techniques.

I've moved all the stuff that should be no longer relevant to here. See WindowsInstallCookbook instead of here. If there is anything you needed in this topic, please comment in WindowsInstallCookbook

  • I suggest that we retire or delete this document by the end 2002.

-- MartinCleaver - 15 Sep 2002

(Attachments are now on this topic, moved from TWikiOnWindows. -- RD)


Re TWikiAlphaRelease as of Apr 2002:

  • There is a lot more code in testenv, and comments in TWiki.cfg, to address TWikiOnWindows issues and to help diagnose common problems. See CookbookActivePerlTestenv to download the latest testenv, which also works on TWiki Sept 2001 or higher.
  • I develop for TWiki using Windows (mainly CygWin) and Linux, which helps to make sure that it works well on both. See WindowsInstallCookbook for the easiest way to install.
  • If you have a choice of Linux or Windows: Linux is about twice as fast as Windows for TWiki, for the same hardware, unless you use ModPerl, which is still not straightforward on Windows.

-- RichardDonkin - 06 Apr 2002

Regarding the Sept 2001 version:

  • JohnTalintyre did his TWiki development alternating between Win2K and Solaris. As a consequence TWiki is now a lot more Windows friendly than any previous version.

  • The main thing to know about is the safeEnvPath feature - new in this version. This must include a reference to $rcsdir so that when rcsdiff runs it can find $rcsdir/diff.exe
  • CygWin needs to be installed but is used only for fgrep, egrep and ls. (This is slightly misleading, albeit unintentionally. CygWin is needed for two things. First to allow Cygwin versions of fgrep, egrep, and ls to run at all, and secondly to cause the underlying Perl shell command processing to be unix shell-like, via the Cygwin provided Bash shell. -- JonathanGBressel - 27 Dec 2001)
  • On Windows ActiveState Perl is preferred, but to use the testenv script first see CookbookActivePerlTestenv.
    • This is no longer true - using CygWin Perl is much easier, since you can install Perl, RCS and Unix tools in one step, and it works well with less configuration hassle in my experience. See WindowsInstallCookbook for the details. [ RichardDonkin ]

If you are using Apache you don't need to rename the .pl suffixes if

  1. you configure your .htaccess file in the bin directory so it will recognize the scripts without the .pl suffix (add AddHandler cgi-script . to it) and
  2. update the she-bang to point to the full path where perl can be found

-- MartinCleaver - 29 Sep 2001

If you have used these instructions and been successful or unsuccessful, can you please add a comment to this page or, preferably, help make this page more readable. I cannot see me having much time to do much more work refactoring this page now, if you feel that you do, please assume ownership :^) -- MartinCleaver (Comments moved to end)

Refactoring in progress..... -- HansDonner

see also:

and have a look at the Windows related topics (a search for now, should be included in the text later on):

Results from Blog web retrieved at 09:35 (GMT)

Results from Codev web retrieved at 09:35 (GMT)

Results from Main web retrieved at 09:35 (GMT)

Results from Plugins web retrieved at 09:35 (GMT)

Results from Sandbox web retrieved at 09:35 (GMT)

Results from Support web retrieved at 09:35 (GMT)

Results from TWiki web retrieved at 09:35 (GMT)

Results from TWiki02 web retrieved at 09:35 (GMT)

Results from TWiki03 web retrieved at 09:35 (GMT)

Some notes on using TWiki on a Windows environment

For an overview of known working Windows environments


In order to run TWiki, the system should comply to the RequiredEnvironmentForTWiki. These include:
  • CGI capable http server
  • Perl 5
  • RCS
  • Access to Unix commands: ls, fgrep and egrep

CGI capable http server

Several qualifying webservers are available. Reported to work:
Web server See also Comments
Apache TWikiOnWindowsUsingApache http://www.apache.org/

Perl 5

ActiveState has a Perl build for Windows

Also Cygwin (see Unix Commands) seems to include a Perl build.


An RCS build for Windows is available from as rcs57pc#.zip. # Can be:
  1. Binary files
  2. Documentation
  3. Source files

Or read the GNU Emacs FAQ For Windows for where to get RCS:

Unix commands

The needed unix commands are included in a unix library for windows called Cygwin

see also:

Adjusting the Windows environment

Have the PATH include the location of

  • the Cygwin's bin directory (depends on installation, may look like \cygwin\bin)
  • the RCS bin directory (depends on installation)
  • the perl bin dictory (depends on installation, in case of ActiveState's version it may look like \perl\bin)

  • [ HansDonner ] I haven't tested if this is really required.

Optionally you could set the PERL5LIB environment variable to the location where the TWiki lib directory can be found (it build the @INC variable used in Perl).

Configuring TWiki

The TWiki.cfg file contains some inline comments regarding the setup on a Windows environment. In the beta of Aug 25th, TWiki tries to identify the system it's run on, and sets some of it's environment specific settings.

  • When specifying paths, use the slash instead of the backslash, eg. "c:/twiki/data"; instead of "c:\twiki\data";
  • You may set the $scriptSuffix to =$scriptSuffix = ".pl" =. This is not required!
    • In case of using apache you could add AddHandler cgi-script . to the apache configuration or to the .htaccess file in the bin directory
    • If you do set it to ".pl", be sure to rename all the scripts in the bin directory, and modify the .htacess file.

Setting up the scripts

The she-bang line has (probably) to be modified. All scripts start with #!/usr/bin/perl. Change the /usr/bin/ part to the directory where perl can be found, like #!/perl/bin/perl. If perl is in the PATH then it could also be just #!perl

  • Note that you can automate this as follows, once Perl is installed.
    • Type the following very carefully at a command prompt - do TEST THIS on a dummy .pl file first. It does back up all Perl files from foo.pl to foo.pl.bak:
      cd twiki\bin
      copy view.pl foo.pl
      perl -pi.bak -e "s;^#!/usr/bin/perl;#!perl;" foo.pl
      type foo.pl
      del foo.pl
    • Once you are happy this is working, just run the Perl command again, using *.pl instead of foo.pl - Perl edits the files in-place.

Old Notes (being refactored above)

WebServer Specifics:

There is a very complete listing of HTTP servers at http://webcompare.internet.com/

Getting RCS to work

From RCSConfigurationOnWindows:

a) Either the USER or LOGNAME variable must contain the user's (i.e. your) last name, unless you have network software installed and want to use the name with which the user is logged on to the network (see below). In this latter case, you need not set one of these variables, if RCS is able to detect the logged on user name.

b) The TZ environment variable should contain your proper time zone definition.

The TZ variable usually contains the time zone name, the time zone offset in hours to GMT and optionally the daylight savings time zone name. Examples are:

SET TZ=PST8PDT (pacific standard time) SET TZ=CET-1 (central european time)

On OS/2, see the emx runtime documentation for a description of the full TZ value syntax.

c) The RCSINIT variable can contain options for RCS you want to use all the time. The default value is suitable for work under DOS and on FAT file systems under OS/2, i.e. all RCS files go into a subdirectory RCS of the working directory and have no special suffix.

If you work under OS/2 on a HPFS file system (or any other file system that can handle long names), you may want to follow the Unix convention of using RCS files in the working directory that may also have a suffix of ",v". For this case, use "SET RCSINIT=-x,v/".

Windows 95 and NT also support long file names and the ,v suffix, but the ,v suffix not on FAT file systems, only on network drives (that reside on OS/2 HPFS or NT NTFS servers or on Unix NFS servers).

See the RCS manual pages for details about all other available options.

d) Make sure you have a properly set the TMP and TEMP environment variables that point to a directory where temporary files should be stored.

e) (this is optional, for OS/2 32-bit executables only)

The RCSLOAD environment variable can be set to a decimal number specifying the amount of minutes to keep the RCS (and diff) executables preloaded in memory. This requires that you have the emx runtime package installed (emxload.exe is required). This method may speed up the use of RCS from within GNU Emacs or with CVS if many files are checked in/out in a batch because that can result in a large number of executed subprocesses with RCS programs.

f) The RCS_LF_ONLY environment variable may be used in mixed platform environments concurrently accessing RCS working files. See below for details.

g) If you are use $safeEnvPath in TWiki.cfg then make sure it includes a routine to the diff command. Without this RCS ci command will silently fail. Would be worth adding this check to testenv

There is some additional useful info, including the URL's of the Windows source distribution for RCS 5.7 (including needed diff and diff3 utils in source), so i'm going to attach the whole readme to this.

Win-RCS-Readme.txt (Info on .exe and src for RCS 5.7 / Diff 2.7.1)

I have RCS working fine under Windows 2000. I had to put -x,v option on the rcs commands (to stop it looking for an RCS directory) and as stated above set TZ environment variable. See latest TWiki.cfg in cvs. Make sure diff with rcs wins over any other diff. This also works for Windows NT 4.

RCS was the big hang up for me. In particular set the -x,v flag on the RCS commands. Also, the Gnu RCS will not behave properly if you do not also set the TZ environment variable to "PST8PDT" (or whatever is appropriate for your time zone).

  • I had the problem that some of the files were not taking changes. It turned out that this was because the web server was not running as 'nobody' but rather as 'SYSTEM' whereas the files concerned (which turned out to be the Web*.txt files used by the system) had all been locked by the 'nobody' user.

  • You can check that they all have the right locks by running this:
    • rlog *.txt | egrep "locked by" | grep -v SYSTEM
      • if that returns anything you have a problem!
      • in which case, trawl through the output of this: * rlog *.txt | egrep "Working|locked by"

Also, if the file revs are not incrementing when saving you need to change the lock owner on the ",v" file, which is by default set to nobody. See TWiki_Installation_Notes for more.

  • (Intermittant) RCS seems to be adding extra CRLFs into the files on checkout.
    1. {I thought this was only for old files - see http://twiki.org/cgi-bin/view/Support/WhyDoLinesComeOutDoubleSpaced).
    2. I now think that it happens due to RCS deciding for itself as to whether a file is binary. For instance, if I cut & paste out of an edit box of a TWiki on a UNIX machine into a new topic hosted on a NT machine I get this behaviour.
    3. Turned out to be because it was not doing binmode properly. There is a description of this elsewhere.

  1. RCSDIFF does not work.
    1. Seems to be the same. Only difference is that TEMP variable might be differently set as system calls show that under TWiki RCSDIFF is writing temporary files to c:\ whereas the same command from the command line writes them to c:\temp.
      • D:\twiki\data\Main>d:/rcsbin/rcsdiff -q -w -b -r1.15 -r1.16 d:/twiki/data/AI/WebHome.txt
      • See attached.

From RCSDiffNotWorkingBetweenRevisions: { Strange one this, and hopefully the last as everything else works. When I click on the <_ buttons the only diffs that work are those between the initial version and the first revision. Subsequent diffs fail for an unknown reason. Anyone seen this problem before?

TWiki version: December 2000 Web server: Apache Server OS: NT4 Sp6a -- MartinCleaver - 27 Feb 2001


It looks like rcsdiff is not working properly. Make sure that the path is set correctly. Also check if rcsdiff works on the shell level, i.e.

rcsdiff -q -w -B -r1.1 -r1.4 WebHome.txt

-- PeterThoeny - 06 Mar 2001

After many struggles (and reading just about every topic related to TWiki Windows installations), I finally seem to have the system up and running on Windows 2000 using Apache and the ActivePerl.

The last problem (and the one that took me the longest to figure out) was related to RCS. I would create a topic, and version 1.1 would be created just fine. However, subsequent edits just continued to modify version 1.1 instead of creating versions 1.2, etc.

It turns out that there is a feature in TWiki that if the same user modifies a document within the locking period (default of 1 hour), a new revision is not created. See the topic MultipleChangesNotIncrementingRevisionNumber for details or the $doKeepRevIfEditLock variable in TWiki.cfg.

-- RandyStephens - 28 Dec 2001

Further User Note

I got this problem on a fresh Solaris 8 box using RCS 5.7.

To fix it I installed the Gnu Diffutils package version 2.7

As far as I can tell the version of RCS requires the Gnu Diffutils to function correctly, otherwise you get exactly the error you saw. Running rcsdiff from the shell gives an illegal option error that comes from diff, which was my clue.

-- SimonClift - 15 Mar 2001

Hmm. Interesting because it always works for me from the command line and only in one instance on the web. The one instance is for the 1.1 to 1.2 revision, subsequently it fails!

-- MartinCleaver - 20 Mar 2001

I had the same problem. My solution was to:

install the GNU diffutils install the GNU RCS tools (using the configure option --with-diffutils) in that order since rcs is dependent on the diffutils. This got me working ok. }

RCS was showing changes that already existed in the history files but was not checking in new changes until added cygwin\bin directory into PATH. We were using Rcs57.zip

Additional Comments About RCS

I believe this should be the fix for Martin's problems with Diff, and with the files being locked by SYSTEM.

By default Apache does not pass on the Win32 environment variables to the scripts. I have written a note about how to enable this in TWikiOnWindowsUsingApache please read those first. This explains why rcsdiff works fine on the command line, but not in the script.

Now for the next one, that only the differences between the inital revisions are displayed in a diff. This is because TWiki sanitises the PATH variable in wikki::initialise to only include '/bin:/usr/bin'. I believe that rcsdiff must need another executable to operate, as adding ';/rcs/bin/win32' to the end of the statement fixes this. Unfortuantely I don't have much PERL, and I cannot see why setting it to $envPath instead did not work for me - Anyone?

Finally, onto the files not being locked by nobody. It appears that Win32 RCS uses the currently logged in user to create the lock. I believe that Martin's machine must be logged in as SYSTEM, as mine was logged in as Server and I had exactly the same problem that he mentioned above. I varied Martin's solution by adding:

to the AUTOEXEC.BAT, and the system now worked fine, using the nobody user for all RCS operations.

-- AndyYelland - 17 Aug 2001

Getting mail to work

TWiki needs to mail out. In versions prior to the March 2001 beta, sendmail was needed to send email notifications, you can ignore this section as SMTP send functionality is built into the capability of TWiki.

Unix based sendmail is not standard with Windows. You could use one of:

  • Shareware Sendmail
  • Blat.exe that comes with NT. (not always -- PL)
    1. blat expects a different command line than that which is supplied by TWiki so would require a code modification. 1 Blat needed to be fully qualified in wikicfg.pm as Windows\system32 was not in PATH. Perhaps Windows\system32 should be in path?
    2. removed line -t switch for blat as got error in Apache error log -
      from [Wed Feb 28 15:45:01 2001] [error] [client] malformed header from script. Bad header=-t does not exist: d:/twiki/bin/register.pl

  • TCMail for NT
  • Postie
    • I know a very good command-line mail utility called Postie that I've used to good effect in various environments, including FoxPro programs and FTP site notification. It's freeware for personal use and a cheap license fee for commercial use. I don't know yet if it will work in place of Sendmail in Twiki, but I'll find out.
    • http://www.infradig.com/ is the URL for the author of the program. *(postie binaries uploaded for convenience, see attachment) postie.zip (Command-line Email Utility)
  • MartinCleaver's hack to use the CPAN mailer from the March 2001 beta.
    • There are various mail tools available from CPAN if you have a smarthost to handle actually getting the mail to its destination. The Net:: and Mail:: bundles have modules for SMTP and POP3 and whatnot.


Known problems and solutions

  1. Change history (WebChanges) didn't work until 1) added cygwin\bin directory into PATH and 2) egrep and grep commands were set without /usr/bin prefixes in wikicfg.
  2. Index (WebIndex) didn't work until 1) added cygwin\bin directory into PATH and 2) egrep and grep commands were set without /usr/bin prefixes in wikicfg.


  • Run testenv.pl from the browser:

I'm trying to get Twiki to run on 2000. I can bring up the "testenv.pl", but when I open the "view.pl" file it comes up showing all of the code.

Any suggestions? I'm running 2000 Advanced Server, sp1, Apache 1.3.14 win32, Activestate Perl 5.6

-- ) am posting a related e-mail:

Subject: [TWiki-Dev] Tainting and Shebang line problems on Windows solved.
Date: Sun, 1 Apr 2001 17:28:17 -0700


I know this should go somewhere in the install doc for TWiki, but i'm not sure where and I leave it to someone else to put it in the correct place (please!). This was in response to a post on comp.infosystems.www.servers.ms-windows. (Before this, I think the TWiki doc (or a user added comment) suggested removing the "-T" in all the .pl files.)

"Dave LeBlanc" <whisper@oz.net> wrote in message news:9a5v4f$fc7$0@ >
> I've found that the option in httpd.conf to use Windows file
> associations instead of shebangs works better for me (you don't have
> to take the shebang line out). (NB: I've not yet gotten any script to
> work either using shebang or file associations where the shebang line
> has the -T switch: you'll get a server error log warning that
> "tainting" happened too late... whatever that means smile
> Change your entry in HKEY_CLASSES_ROOT\perl\shell\open\command to say
> "c:\path-to-perl\perl.exe" -T "%1" and all should be well (obviously
> c:\path-to-perl is whatever it is, I'm not being literal there!)

<-My added sig since he didn't sign it.

NOTE: In the above registry entry, DO NOT add the outer enclosing quotes - regedit does those automagically. Quote only the arguments ("-T %1"). Also, my registry entry had the trailing %* outside the quotes, which i'm betting grabs all the arguments, if any. My registry entry looks like this now:

I:\Perl\bin\Perl.exe "-T %1" %*

Unresolved issues

  1. Ref-by wasn't working; a bit of poking around in wikisearch.pm revealed that webList isn't being set. I don't know why. I have hacked it in the meantime:

    if ($#webList == 0) {
       @webList = ( "AI" );  
(actually, the version on our server sets it to whatever the last web was. I don't have access to that at present).

Possible Explanation and Alternate Fix

I had the same problem as well, and traced it back to the point that the code resolves $webStr from the query in search. For some reason (I have no idea - anyone?) the CGI module returns the GET variables seperated by semi-colons ';' instead of the ampercand '&' that the script expects.

This change in search will now split the query string on ';' and search for 'web=' in each scalar and joining them back together to make a space seperated a list.

    my $websStr       = join ' ',
                        grep { s/^web=(.*)$/$1/ }
                        split(';', $query->query_string);  #AJY For some reason the CGI routines on Win32 are substituting ';' for '&' #  split('&', $query->query_string);

Note: This was affecting the all searches from the search page as well; however they were defaulting to the current web only.

-- AndyYelland - 18 Aug 2001

The problem seems to be solved as of today. Well, I couldn't reproduce it.

-- JoachimDurchholz - 20 Nov 2001

Notes on Authentication

  • Any notes you have on this go in the topic related to your webserver.

Notes on security

I'm giving Twiki a try on NT. I'm getting this error on the "view.pl" file:

Too late for "-T" option at C:\webroot\twiki\bin\view.pl line 1.

Twiki comes up if I take out the "T" option on line 1. Any suggestions? Running NT 4.0, sp6a, IIS 4.0, Activestate Perl 5.6. at home, Win2K, sp1, IIS 5.0 Activestate Perl 5.6 at work.

[Main.JoachimDurchholz - 06 Jul 2001] With the -T switch, Perl considers all strings that come from the outside world as "tainted"; Perl will not execute any shell commands that are constructed from tainted strings. The taint "carries through": any string constructed using a tainted string will itself be tainted. The only way to "untaint" a string value is to extract a substring using a regular expression.

The motivation is security: Perl should not execute shell commands constructed from user-provided strings, unless it has checked that these strings are harmless. (This prevents plots like a user providing an email address like "myself@here.com; rm -rf /", which when added to a sendmail command would give "sendmail -q myself@herePLEASENOSPAM.com; rm -rf /".)

The "Too late for "-T" option" message means that Perl is already running, and it can't activate taint checking in mid-track. Not sure why this happens; maybe you're calling Perl from a Perl script. Run Perl from a shell script, then everything should be working fine.

  • [ RichardDonkin ] - This is probably a consequence of defining perl.exe as the shell-open command in the registry, mentioned above. I haven't tested this, but what is probably happening is:
    1. User requests view.pl as CGI request.
    2. Web server opens view.pl, causing perl.exe to run on the file
    3. Perl looks at the first line of view.pl, tries to apply the -T option, and complains, because this can only be done when first launching Perl, not after it is running (I think)
  • The workaround is probably to move the -T option into the registry, as mentioned. You could also just run pl2bat (part of the Perl distribution for Win32) on the TWiki .pl files, generating .bat files that work as if Windows had a shebang feature for scripts - see this FAQ entry for more information), this would require that .bat was defined as the script suffix and is fairly horrible looking.

Notes on how TWiki On Windows is different to TWiki On Unix

(Refactored into TopicCaseSensitivity)

Thoughts on Corporate setting

I just installed successfully the TWiki on my Windows running notebook computer. I am testing about now if all the features are working away. As doing a documentation (software requirements and a how-to-install) for my co-workers I would be proud to give this away to everyone else like it. In addition of this I started working on a new feature to update changes between my notebook-TWiki and the corporate intranet-TWiki.

See ReadWriteOfflineTWiki - MichaelSparks is working on this.

Synchronize notebook-TWiki and corporate intranet-TWiki: This has been discussed as a brainstorming idea. Please read OfflineWiki, then let's discuss your idea in one of the topics starting at OfflineWiki (ReadOnlyOfflineWiki, ReadWriteOfflineWiki) before you start with the implementation. (ReadmeFirst tells you more about contributions)

Installing TWiki on win2k - no big deal, I think

In response to the many helpful directions on this page and the one for TWiki/Apache I want to share my installation experiences. Hopefully we can simplify this page and prove that installation on windows is a breeze with the right instructions. (Please note that at this point I have not bothered testing the RCS and have not even installed a mail utility, just getting TWiki to show up in the browser correctly.)

  • I downloaded the cygwin utilities and RCS following the TWiki links. I installed them in c:\apps\cygwin and c:\apps\rcs, respectively. I installed TWiki in c:\twiki . Of course it does not really matter much where all of this gets installed although I took one advice to avoid spaces in the resulting paths (Program Files is the defualt for Apache). Not sure if it matters (for Apache it should not, I think).
  • I downloaded the AnalogX server which indeed installs real easily. Unfortunately it turned out to be the biggest time sink since, being a newbie, I spent a lot of time on getting the cgi-bin to work. According to the documentation it should work if you put the scripts in a directory called cgi-bin under the AnalogX web root. Up until now I have not been successful with that. I also don't like being forced into a directory structure. Therefore I switched to Apache.
  • I downloaded Apache and installed it in c:\apps\apache as a console app (not as a service - we need to start/stop it all the time while testing). I entered dummy names for the domain and server - as long as localhost works, I'm happy.
  • In Apaches httpd.conf I made the following changes:
    • DocumentRoot "C:/twiki"
    • <Directory "C:/twiki">
    • (Right before the first ScriptAlias statement, following helpful directions by the "lesser animal" on the Twiki/Apache page)
Alias /twiki/ "C:/twiki/"
ScriptAlias /twiki/bin/ "C:/twiki/bin/"
<Directory  "C:/twiki/bin/">
    AllowOverride None
    Allow From All
    Options  ExecCGI
    SetHandler cgi-script 
  • In every perl script that has a shebang line, change it to something like "#!c:/apps/cygwin/bin/perl -wTI." (Or wherever you have your perl. Don't incude the quotes of course and note that the -wTI. option may not be the same for every file). Don't use a UNIX-like path like /usr/bin/perl because Apache does not know where your cygwin root is - it's intalled under Windows.
  • The wikicfg.pm file was changed to
#                   /cgi-bin/view/Main/WebHome : link of TWiki icon in upper left corner :
$wikiHomeUrl      = "http://localhost/twiki";
#                   Host of TWiki URL :    (Example "http://myhost.com:123")
$defaultUrlHost   = "http://localhost";
#                   /cgi-bin : cgi-bin path of TWiki URL:
$scriptUrlPath    = "/bin";
#                   /p/pub : Public data path of TWiki URL (root of attachments) :
$pubUrlPath       = "/pub";
#                   Public data directory, must match $pubUrlPath :
$pubDir           = "c:/twiki/pub";
#                   Template directory :
$templateDir      = "c:/twiki/templates";
#                   Data (topic files) root directory :
$dataDir          = "c:/twiki/data";
  • You need to update the RCS dir further down as well.
  • NOTE: I did not add the .pl extension to the Perl files, just left it as is. In fact if Windows already associated the .pl extension with a Perl executable, then it becomes really confusing when you enter URLs with that extension in the browser.
  • I added the cygwin/bin and rcs/bin/win32 directories to the path in Windows. I did not experiment with what happens if you don't.

Well that's it. All pretty straightforward steps once you know them. I welcome any comments, and acknowledge that I used some helpful instructions by others here and there on these pages. Also I did not do a very thorough installation and test job, but it took me a day to get to this point so hopefully this helps.

Henk Aling.

Altering the sourcecode

  1. Mailnotify comes up with errors:
D:\twiki\bin>perl mailnotify.pl
defined(%hash) is deprecated at mailnotify.pl line 88.
        (Maybe you should just omit the defined()?)
TWiki mail notification
- to suppress all normal output: mailnotify -q
Checking TWiki.AI
- Changed topics since 27 Feb 2001 - 09:57: TWikiInstallProblems
- Sending mail notification to: Martin.Cleaver@BCS.org.uk
-t does not exist
- End Twiki.AI, mail notification sent
Checking TWiki.Know
- Note: No topics changed since 29 Nov 2000 - 02:58
Checking TWiki.Main
- Note: No topics changed since 02 Mar 2001 - 10:20
Checking TWiki.Test
- Note: No topics changed since 29 Nov 2000 - 02:59
Checking TWiki.TWiki
- Note: No topics changed since 02 Mar 2001 - 10:02
End Twiki mail notification

sub htpasswdGeneratePasswd
    # Changed by MartinCleaver to store unencrypted as this is what Apache requires.
    my ( $user, $passwd ) = @_;
    return "$user\:$passwd"; # EARLY RETURN
    # by David Levy, Internet Channel, 1997
    # found at http://world.inch.com/Scripts/htpasswd.pl.html
    srand( $$|time );
    my @saltchars = ( 'a'..'z', 'A'..'Z', '0'..'9', '.', '/' );
    my $salt = $saltchars[ int( rand( $#saltchars+1 ) ) ];
    $salt .= $saltchars[ int( rand( $#saltchars+1 ) ) ];
    my $passwdcrypt = crypt( $passwd, $salt );
    return "$user\:$passwdcrypt";

Note: If you to have an encrypted password file under Win32 see the note ApachePasswords

  • I had the problem "Lock files are not being removed after a file is being edited meaning that you have to break the lock whenever you edit a page. This has the knock on effect of forcing a new version to be stored in revision control even if the edit is recent and by the same person as the previous edit."
    • Reply on http://twiki.org/cgi-bin/view/Support/RCSProblemsOnWindows says:
      • .lock files get purged by the mailnotify script, so they only get removed if you call it frequently. It does not matter if they are not removed because TWiki checks the timestamp to determine if a topic is still locked. Not sure why this would not work on Windows though.

    • Resolution:
      • I altered the code in Wiki.pm to set all filehandles to binary mode. This means that they use the UNIX format rather than the NT format files. The reason this is important is that the code was written to assume UNIX conventions. Hence, the code assumes /n when actually it will be getting /r/n. This fix means that you no longer get "file locked by someone else" when actually it is you that is editing the file.

Credits (in a-z order):

(If I left you out please add yourself!)

Note: Is this the right place (web) for this topic? I think TWiki or Support would be better places (and maybe splitting this topic up in sections like TWikiOnWindowsAndRCS) -- HansDonner - 22 Aug 2001

I agree you Hans, a final manual style doc does need putting into the TWiki web, but before that can be done it has to be coherent. Unfortunately I have no time or resources to help finish this task, hence my invite for someone to take over from me. Conversations that spring forth from it should indeed continue to be held in topics such as TWikiOnWindowsAndRCS in Codev or Support. (Smart idea for the embedded search BTW) -- MartinCleaver.

I'll try to find some time to do some of the refactoring -- HansDonner - 22 Aug 2001

-- MartinCleaver - 15 Sep 2002

Content below moved from TWikiOnWindows on 28 Sep 2007, as it's mostly very out of date -- RichardDonkin

Theoretically there are many possible ways to run TWiki on Windows, depending on which version of Perl, what webserver, whether CygWin is involved, whether you use ModPerl, how you do authentication and whether you use RcsLite.

WindowsInstallCookbook gives the official 'cookbook' approach to installing on Windows - it works well without errors as long as you use the components it's been tested with. That approach is advised for the casual user as it has been tested a lot and avoids many of the pitfalls of the other combinations of components.

The Big Picture - Variations on WindowsInstallCookbook

The cookbook approach is to make Windows more compatible with UNIX (for ease of TWiki installation), by using CygWin and Apache - this is very well tested.

This topic discusses some other, less tested methods. We do this because:

  • Some places will prefer to use a different webserver:
  • Some places will want to avoid the use of CygWin
    • There are no known issues with it but that doesn't mean we get no resistance from our colleagues
  • Some places will prefer to use ActiveStatePerl
  • Some places will want to use ModPerl

Each permutation has its own foibles. Trust me, use the cookbook approach if you don't know what you are doing.

TWikiOnWindowsKnownConfigurations lists some known setups. Not all of them are necessarily still running nor are all setups in use listed. We encourage you to list your setup on that page. This page shows the theoretical combinations and which ones might be worth trying.


  • R=Reproducability
  • D=Desirability

Class of WebServer Class of Perl CGI Auth RCS utils R? D? Topic
WindowsApache CygWin cmdline CGI Basic CygwinRCS Cygwin Y 3 WindowsInstallCookbook
WindowsApache CygWin ModPerl ModPerl Basic CygwinRCS Cygwin N 2 Beware mixed environment. WindowsInstallCookbook points to WindowsModPerlInstallCookbook but that requires a change of class of Perl
WindowsApache ActiveState cmdline CGI Basic CygwinRCS Cygwin N 3  
WindowsApache ActiveState ModPerl ModPerl Basic CygwinRCS Cygwin Y 4 WindowsModPerlInstallCookbook
CygwinApache CygWin cmdline CGI Basic CygwinRCS Cygwin N 3 30% slower than WindowsApache but supported by TWikiUnixInstaller
CygwinApache CygWin ModPerl ModPerl Basic CygwinRCS Cygwin N 3 TWikiUnixInstaller can give you a head start; then see CygwinModPerlInstallCookbook
CygwinApache ActiveState cmdline CGI Basic CygwinRCS Cygwin N 1 Beware mixed environment
CygwinApache ActiveState ModPerl ModPerl Basic CygwinRCS Cygwin N 1 Beware mixed environment - this is unlikely to work
Windows IIS CygWin cmdline CGI Basic CygwinRCS Cygwin N 3 CookbookWindowsIISSetup
Windows IIS CygWin ModPerl ModPerl Basic CygwinRCS Cygwin N 1 Beware mixed environment
Windows IIS ActiveState cmdline CGI Basic CygwinRCS Cygwin N 4 MartinsInstallOnIIS might work
Windows IIS ActiveState ModPerl ModPerl Basic CygwinRCS Cygwin N 5 MS sell a ModPerl replacement for IIS, if my memory serves.
Windows 2003 IIS 6.0 UnixServicesForWindows 3.5 CGI none yet UnixServicesForWindows 3.5 UnixServicesForWindows 3.5 Y Y TWikiOnWindows2003
IndigoPerl IndigoPerl IndigoPerl ModPerl Basic RcsLite PurePerlBackendForSearch, GnuWin32 - - TWikiOnWindowsUsingIndigoPerl
IndigoPerl IndigoPerl IndigoPerl ModPerl Basic RcsLite PurePerlBackendForSearch, GnuWin32 - - TWikiOnWindowsUsingIndigoPerl

See also TWikiOnWindowsKnownConfigurations for specifics.

Notes on the above table

  • Desirability is defined as being the least shock possible for the CorporateWorld, where 5 means we use all the things they expect and 1 is we cram lots of 'wierd' things on their machines. For Windows, IIS and AS Perl are therefore deemed more 'desirable' than Cygwin and Apache.
  • Beware mixed environment flags combinations that are not very sensible (indeed, sometime not possible). An example would be to use Windows Apache to call CygWin ModPerl. That would be stupid because if it worked it would involve crossing windows/CygWin paradigms on every topic hit.

-- MartinCleaver - 11 Jul 2003


  • Up to now most people have used CygWin - GnuWin32 may allow us to eliminate this emulation layer.

Help wanted

Scattered about on TWikiDotOrg are known good configurations for things like Windows Apache + ActiveStatePerl + ActiveState ModPerl. I would find it very helpful if you could help refactor them, create new topics where necessary and point this topic to point to those topics.


I see you have cygwin-apache with cygwin-perl as Not Reproducible. Does this mean you haven't been able to reproduce it or that there is no topic describing how to do it?

I have cygwin-apache with cygwin-perl running. It didn't take anything special: Use the cygwin setup program to install cygwin, apache, & perl, then install twiki according to the regular Installation Guide.

-- MattWilkie - 12 Jul 2003

I meant that I hadn't heard of anyone successfully using it smile I'm glad that you are.

So I can update the table, are you using a CygWin ModPerl with this as well? If not, did you try to?

Nope, haven't tried. -- MattWilkie - 14 Jul 2003

-- MartinCleaver - 12 Jul 2003

I've made some minor edits above - the main idea of WindowsInstallCookbook was just to use something that was well tested, though I do have a preference for Unix tools since I develop for TWiki and also use Linux. Using Apache was also convenient for developing the cookbook on a laptop, since nobody was going to pay for a copy of Windows Server (to get IIS) on my laptop!

The pro's of using IIS are, as I see them:

The pro's of using Apache are:

  • Easier to document installation since it's based on config files (no built-in GUI tools)
  • Much more Apache experience with TWiki sites, and may be easier to install successfully
  • Free, even for desktops/laptops
  • Historically has had less frequent security holes than IIS
  • Very good performance with ModPerl, which is free
    • IIS would require a commercial Perl add-in to achieve similar performance

-- RichardDonkin - 14 Jul 2003

TWikiSiteTools documents how to run a scheduled task on Windows for WebChanges notification. CronTabWin is a free scheduler for Windows.

-- PeterThoeny - 03 Aug 2003

I've seen several broken links to CookbookWindowsIISSetup leading me to believe that this page used to exist, rather than not created yet. This soulds like exactly what I need to get started. Does anyone know what happened to this information?

-- MichaelSachtjen - 31 Mar 2005

Michael, Just an FYI in case you haven't tried it more recently, but the CookbookWindowsIISSetup page is up at this time.

-- AmandaSmith - 15 Nov 2005

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatZIP SM1121.ZIP r1 manage 1339.2 K 2002-07-21 - 21:13 MarkusKling Microsofts sendmail port
Compressed Zip archivezip postie.zip   manage 388.1 K 2000-11-10 - 02:37 GwendolynPatton Command-line Email Utility
Compressed Zip archivezip tcmail.zip   manage 19.4 K 2000-08-30 - 17:24 UnknownUser TCMail Mail Client Utility 1.01
Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r3 - 2007-09-28 - RichardDonkin
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.