1. Comment on the testenv program:
   • It should pick up the name of the ci program from the TWiki.cfg file as on windows it is ci.exe not just ci.
2. Comment on the TWiki.cfg script:
   1. Factor out the names of the RCS scripts so they occur exactly once.
   2. On Windows add a $dotExe variable onto the variable names. This way it tests for the files existing as well as working when called as an executable.

-- MartinCleaver - 26 Sep 2001

Note that this also applies to Cygwin (which behaves Unixish in other respects).

-- JoachimDurchholz - 23 Nov 2001

(Copied above text from the Support web)

This is an enhancement that will make TWikiOnWindows Installations easier, is now a FeatureToDo item.

-- PeterThoeny - 24 Nov 2001

This is now in TWikiAlphaRelease, apart from factoring out the names of the RCS scripts (not sure why that's useful as they won't change).

-- RichardDonkin - 26 Mar 2002

The current version of TestenvCgiScript tries to retrieve the executable file suffix from Config Perl module (in order to test for existence of $rcsDir/ci.$exeSuffux). This doesn't work (at least, on my version of ActivePerl), so TestenvCgiScript inconsistently complains about not being able to find ci program. Similarly, TestenvCgiScript tries to append his $exeSuffix to filenames that are extracted from $lsCmd, $egrepCmd and $fgrepCmd. However, since $exeSuffix is empty (for my configuration), this works as soon as $lsCmd and the other variables contain filenames with .exe suffix.

This misfeature/bug severely complicates setting up TWikiOnWindows (with RcsWrap), along with at least two other RCS issues ($safeEnvPath configuration and TZ environment variable). I think it should be resolved by creating $exeSuffix configuration variable (which would be automatically derived from $OS in TWikiDotCfg) that should be inserted in $lsCmd, $storeSettings{initBinaryCmd} and so on, and used in TestenvCgiScript. Also, TestenvCgiScript should maybe extract ci executable filename from $storeSettings{ciCmd}, as it does for ls executable filename, and not to use $exeSuffix (explicitly) at all.

-- PavelGoran - 21 Jul 2003

Seems that the Config module is not working on your setup - just tested this on ActivePerl 5.6.1 build 631 and it works fine:

$ perl -v

This is perl, v5.6.1 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2001, Larry Wall

Binary build 631 provided by ActiveState Tool Corp. http://www.ActiveState.com
Built 17:16:22 Jan  2 2002


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.


rdonkin@WLORDONKIN ~
$ perl -e 'use Config; print "$Config::Config{q{_exe}}"'
.exe

The idea is to have the TWiki.cfg settings use paths to program files without specifying .exe (as is normal on Windows and Unix), then testenv suffixes the OS-specific .exe to check if the files really exist. Since this is a problem on a specific version of ActivePerl, I don't think testenv should change. $detailedOS is also derived from the Config module, so if this is not working you may have other problems.

-- RichardDonkin - 21 Jul 2003

Thank you for providing an example of using Config module - without it, it might take a long time to find out that Config::Config{'_exe'} fails simply because Config is (usually) not imported by TestenvCgiScript .

I understand the idea of having command lines without appended $exeSuffix, but I had an impression (which turned out to be wrong) that TWiki doesn't properly work unless .exe is appended to filenames in command lines. Now I see that my proposal of using $exeSuffix in TWikiDotCfg doesn't have much sense. However, TestenvCgiScript still needs to be fixed (which is trivial).

... One more comment: TestenvCgiScript behaves inconsistently when $egrepCmd (for example) has spaces in it. It first appends $exeSuffix to the command line, and then strips its tail, beginning from the first space. I can think of two causes of having spaces in command lines, which are best described with examples:

1. c:\Program Files\UnxUtils\ls
2. c:\UnxUtils\grep -E (this is close to my case)

In both cases, the current filename extraction logic in TestenvCgiScript would not work properly. Is it worth fixing, or such command lines are unsupported and should be avoided anyway?

-- PavelGoran - 21 Jul 2003

I'm fixing testenv for the Config issue, thanks for spotting this and reporting it, even though I didn't quite believe you at first ... As you point out, it was only loaded conditionally so would probably only work for upgrades over Dec 2001 TWiki code. From 23 Jul 2003 (SF's ViewCVS is 24 hours out of date), see CVS:bin/testenv for the change, tested on Cygwin Perl, ActivePerl and Linux, and CVSget:bin/testenv to download, or the attached patch file if you are in a hurry. Interestingly, there was another bug masked by this issue, which meant it always worked on Cygwin Perl and never on ActivePerl. So probably there are very few people using ActivePerl and not upgrading from Dec 2001 release, or they just ignored that message.

Re the spaces in pathnames issue - I'm not going to fix the first case (spaces in pathnames) as this is a bad idea since many Perl/Unix utilities don't react well to pathnames with space in them, and of course very hard to code if the second case is fixed. However, I will fix the second case at some point - or include a patch if you want to fix this yourself!

-- RichardDonkin - 22 Jul 2003