Question

• TWiki version:
• Perl version:
• Web server & version:
• Server OS:
• Web browser & version:
• Client OS:

mailnotify seems only to run correctly when invoked in twiki/bin.

I.e. it depends on the path from which it was invoked. This is bad programming practice. Perl FindBin should be used.

Also, it gets in the way of the usage model where several different installations share the same twiki/bin.

-- AndyGlew - 27 Jun 2003

Answer

Trying this out, it has pros and cons.
Pros:

• "Correct" way to do this.
• Means that scripts can be run from anywhere on the filesystem, not with a CWD of the bin directory

• Is the wrong way to do this:

FindBin(3)     User Contributed Perl Documentation     FindBin(3)
KNOWN ISSUES
       If there are two modules using "FindBin" from different
       directories under the same interpreter, this won't work.
       Since "FindBin" uses "BEGIN" block, it'll be executed only
       once, and only the first caller will get it right. This is
       a problem under mod_perl and other persistent Perl envi­
       ronments, where you shouldn't use this module. Which also
       means that you should avoid using "FindBin" in modules
       that you plan to put on CPAN. 

Given...

• Many people want to get TWiki to the level of being suitable for packaging up for CPAN (whether the CPAN is used as an installer of not)
• This won't work reliably in mod_perl or persistent environments.

If anyone wants to try it though, the code they need is this:

• replace BEGIN { unshift @INC, '.'; require 'setlib.cfg' }
• with:

BEGIN {
 use FindBin qw($Bin);
 $Bin =~ m/^(.+)$/;
 $bin = $1; }
use lib "$bin/../lib";

• Also you need to place braces around the entirety of the rest of the script.

You had	You Need
use CGI::Carp qw( fatalsToBrowser ); use CGI; use TWiki; use strict; &main(); ... # print page content print $tmpl; writeDebugTimes( "view - done" ); } # EOF	{ use CGI::Carp qw( fatalsToBrowser ); use CGI; use TWiki; use strict; &main(); ... # print page content print $tmpl; writeDebugTimes( "view - done" ); } } # EOF

The untaint is deliberately bad. If someone wants to take this forward investigating whether this will work better in setlib.cfg instead strikes me as more sensible. The mod_perl issue would need resolving as well. Looking at FindBin, it's just perl (no extensions/etc) so if you want to spend the time creating a version that doesn't have these problems (which noone has addressed between perl versions 5.005 and 5.8), that'd be useful.

Whilst the current method sucks a touch, it's a lot better than the downsides this method provides.

-- TWikiGuest - 28 Jun 2003

This has come up before:

• http://TWiki.org/cgi-bin/view/Codev/SettingLibPath#ModPerlAndSetLib

Looks like I've solved the taint problem (albeit with a naff untaint) that describes, but as the page describes FindBin does indeed cause more problems than it solves. The page also describes the background that led to the decision to do it the current way. I'd extra comments there if you've got a nice solution

-- TWikiGuest - 28 Jun 2003

Confusion!

FindBin is best used in scripts designed to be executed from the command line. Not in modules designed to be in a library like CPAN.

I.e. put FindBin in the twiki/bin/view script, etc., not in the TWiki.pm modules (and hopefully the large set of other modules that will be developed).

-- AndyGlew - 30 Jun 2003

The TWikiSiteTools docs state to cd first to the bin directory:

15,45 * * * * (cd ~twiki/public_html/bin; ./mailnotify -q)

Is there a condition where this is not feasible?

-- PeterThoeny - 30 Jun 2003

Q: "Is there a condition where this (cd'ing) is not feasible?"

1. To a first order, not really... but anyone who has done a lot of UNIX programming will be familiar with the notion that CWD dependent scripts are bad programming practice.

2. Actually, I do have a condition where this cd'ing is not feasible. Two. You may not care about them, since it is a non-standard twiki installation; but there apppeas to be no other way of obtaining satisfactory security.

As described in DifferentSecurityLevelsInSameTWikiInstallation, I set up an installation where multiple cgi-bin directories contain setgid scripts, that perform slightly different permissions checks, and which then exec the scripts in twiki/bin. I.e. the twiki/bin scripts are shared between several different twikis.

Each cgi-bin directory contains its own setlib.cfg, and each has a slightly different include path, to get a slightly different TWiki.pm.

In this setup, executing CGIBINXXX/view works, and execs twiki/bin/view, but executing twiki/bin/view without executing CGIBINXXX/view to set up the environment doesn't work.

So much for view. The same applies to mailnotify.

Can I change my setup to get twiki/bin/mailnotify working? Yes.

Is it good programming practice for mailnotify to be CWD dependent? No.

PS. documenting a bug does not make it not a bug; it just makes it a documented bug. CWD dependence is a bug, albeit a design bug,not a codiing bug.

-- AndyGlew - 01 Jul 2003

CPAN:FindBin is not a great solution as it introduces its own problems (which is why SpamAssassin recently dropped this). I agree mailnotify should be cwd independent but it needs to pick up the TWiki.cfg from somewhere - the easiest way to do this is for it to load setlib.cfg like everything else.

If you can't cd into the bin directory you may well not be able to run scripts there or cd into other required directories.

Doing mailnotify without cwd dependence would require an environment variable or similar, and mailnotify would then do an internal cd, or concatenate this onto paths. It could be done but I'm not sure why requiring an external cd is such a bad idea - it's also not clear what the best change is to satisfy your environment as well as ModPerl etc.

-- RichardDonkin - 01 Jul 2003