Question

My WebSearch doesn't work, just like described in WebSearchProblem. (I've also noticed that WebChanges and Backlinks return empty results, too.) Exactly as pointed out in WebSearchProblem, I think the problem must be the availability of egrep and fgrep. testenv seems to confirm that as it warns me that egrep.exe and fgrep.exe can't be found. In fact, the cygwin folder does not contain "egrep.exe" and "fgrep.exe" files, but plain "egrep" and "fgrep" files. (I have entered $egrepCmd and $fgrepCmd in TWiki.cfg without the exe extension.)

The egrep and fgrep commands work when invoked from the Cygwin shell, so I assume that it is normal that Cygwin does not provide these as exe files.

How do I make TWiki use the Cygwin functionality to fix WebSearch?

Environment

-- HenningRuch - 25 Nov 2004

Answer

Workaround: I copied grep.exe as egrep.exe and fgrep.exe into the cygwin binary folder (where grep.exe resides, too). Now I get results for all of the actions described above.

I'm not confident yet that this means I've got a WebSearch that's fully functional under all circumstances. Expert advice would be appreciated!

-- HenningRuch - 26 Nov 2004

Thanks for attaching testenv output (so few people do!). Actually the problem here is XAMPP's Perl. TWiki does work with XAMPP on Windows as far as I can tell. Everything should work OK with your current setup, though you may need to do similar things with RCS (i.e. copy rcs to rcs.exe). Note that as of TWikiRelease01Sep2004, there is no need for ls despite it being listed in $lsCmd in TWiki.cfg.

The problem is that XAMPP Perl (really ActivePerl build 810 in the Perl Add-on) wants to see .exe suffixes on things, and probably adds them automatically - as testenv points out, this is a problem, so your action of creating the egrep.exe and fgrep.exe binaries is the right approach.

-- RichardDonkin - 26 Nov 2004

Hm, how do I find out which Perl I'm actually using? As far as I can tell, it's the one that came with the Xampp for Windows package. (I'm really a bit out of my element - to be honest, I installed TWiki simply by following the instructions on the box.)

-- HenningRuch - 26 Nov 2004

Try doing perl -v and perl -V to get the Perl version.

-- RichardDonkin - 27 Nov 2004

I've uploaded the output for the Perl I'm using. It looks like it's not SiePerl, though.

-- HenningRuch - 01 Dec 2004

Thanks for the updated info. Looks like it's ActivePerl 5.8.4, which is not too bad - however, it may have been customised by the XAMPP project which explains why testenv did not detect it. You have apparently installed the 'Perl addon' for XAMPP for Windows, which updates the built-in Perl (perl -v reports ActiveState? build of 5.8.4).

For anyone else reading this - XAMPP includes a really useless version of Perl (5.8.3, only two files in bin directory) as of XAMPP 1.4.9 - so be sure to install the 'Perl Add-On' which updates the Perl to be usable for TWiki.

The perl -v output once XAMPP's Perl Add-On is installed is:

$ ./perl -v

This is perl, v5.8.4 built for MSWin32-x86-multi-thread
(with 3 registered patches, see perl -V for more detail)

Copyright 1987-2004, Larry Wall

Binary build 810 provided by ActiveState Corp. http://www.ActiveState.com
ActiveState is a division of Sophos.
Built Jun  1 2004 11:52:21

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'.  If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.

$ ls -l
total 1364
-rwxr-xr-x    1 rdonkin  None       634880 Apr  7  2004 perl.exe
-rwxr-xr-x    1 rdonkin  None       761856 Apr  7  2004 perl58.dll

$ ./perl -v
This is perl, v5.8.3 built for MSWin32-x86-multi-thread

Copyright 1987-2003, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'.  If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.

-- RichardDonkin - 06 Dec 2004

Renaming this topic to reflect use of XAMPP not SiePerl.

Having done a test install of XAMPP 1.4.9 and the Perl Add-on 1.4.9, XAMPP does seem to work with TWiki (though I didn't fix all the issues, it did generate a page - some problem with the skin). Also, the use of Apache 2 causes some issues with non-UTF-8 URLs (see EncodeURLsWithUTF8) being caught and converted by Apache before TWiki sees them, causing problems with Firefox/Mozilla (see ApacheTwoBreaksNonUTF8EncodedURLsOnWindows). Hence Apache on Windows is not great for I18N at present, since the problem is Apache trying to map UTF-8 onto Windows filesystem APIs that support Unicode.

-- RichardDonkin - 07 Dec 2004

Thanks, that's exactly my installation! (Except that my Perl add-on seems to be a bit older and doesn't contain the three patches.) Generally, internationalization is an issue for me since I'll be running a German site where Umlauts are inevitable, but the Windows setup is just for general testing of the TWiki capabilities and the "real" site will run on a Linux/Apache 2 system anyhow. Is it correct that

• TWikiRelease01Sep2004 is the CairoRelease? ,
  • Yes, but use TWikiRelease02Sep2004 since it includes an important patch --RD
• UTF-8 is supported in the CairoRelease, and
  • Only partially - UTF-8 URLs pointing to TWiki topics are decoded correctly into ISO-8859-1 (or virtually any other site character set (EncodeURLsWithUTF8). However, full UTF-8 support is not included - see ProposedUTF8SupportForI18N. -RD
• Apache 2 under Linux does not cause the I18N issues you mentioned in a Xampp context?
  • This would almost certainly be OK, since Apache on Linux does not try to convert UTF-8 URLs at all. Apache 1.3 would be fine on either platform. --RD

-- HenningRuch - 07 Dec 2004

See comments above under your bullets.

-- RichardDonkin - 07 Dec 2004

Thanks again - it seems ISO-8859-1 covers all seven German special characters, so I'm completely happy now!

-- HenningRuch - 07 Dec 2004

Glad to have another happy user of I18N - and it's been interesting to find out about XAMPP. I have seen some notes that XAMPP is not very secure by default, so you may want to ensure there are good passwords on all servers etc, and to see if there are any best practices.

-- RichardDonkin - 08 Dec 2004

The I18N bug mentioned above mainly affects Firefox/Mozilla on Apache 2 for Windows - see Codev. ApacheTwoBreaksNonUTF8EncodedURLsOnWindows.

-- RichardDonkin - 09 Dec 2004

• testenv.html: HenningRuch testenv