Item10717: Improved bin script code that finds the executable script on the path.

When I simply try to edit a topic, I get this annoying error: Can't locate /usr/bin/setlib.cfg in @INC.

Apparently SvenDowideit has encountered this some time ago
http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2010-11-22,Mon&sel=38#l34
with a possible bug in FindBin: http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2010-11-22,Mon&sel=136#l132

According to George Clark on IRC:
if the script is found elsewere in the default path on the system FindBin gets lost. for ex. /usr/bin/view vs. foswiki/bin/view .... or something like that

This is my setup:

Perl version

5.010000 (linux)

@INC library path

/home/me/mysite.com/fw/core/lib
/etc/perl
/usr/local/lib/perl/5.10.0
/usr/local/share/perl/5.10.0
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.10
/usr/share/perl/5.10
/usr/local/lib/site_perl
/home/me/local/lib/perl5
/home/me/mysite.com/fw/core/lib/CPAN/lib/arch
/home/me/mysite.com/fw/core/lib/CPAN/lib/5.10.0/x86_64-linux-gnu-thread-multi
/home/me/mysite.com/fw/core/lib/CPAN/lib/5.10.0
/home/me/mysite.com/fw/core/lib/CPAN/lib 

-- ArthurClemens - 05 May 2011

FindBin doesn't care about the @INC path, it traverses the env PATH - so i gues a work around is to unset that...

just to confirm - setting {SafeEnvPath} to '/' prevents this issue. setting it to a dir that the user can't access results in a taint crash, and setting it to something containing ~ appears to quietly set it back to an empty string, which means it gets defaulted back to /usr/local/bin:/usr/bin:/bin or something, which also sux.

-- SvenDowideit - 06 May 2011

Yeah, but I thought we agreed my fix was a stupid idea and it should be reverted, the same way Kenneth reverted it in the release branch.

I'll do that on trunk too.

-- OlivierRaginel - 06 May 2011

Reverted in distro:41681eafe4ab

Odd thing is that the bin scripts are still not the same on trunk and in the release branch. I wrote code to use File::Spec, which I guess got reverted on the release branch too. The main advantage of that was that all scripts are identical, so we could symlink them or something, to ease the maintenance. Anyway, closing this task now as it was reverted, so it should be fine for Arthur now.

Setting to close as this was already done in the release branch, so it's just to put trunk up-to-date, hence no need to mention it in the release notes.

-- OlivierRaginel - 06 May 2011

Revert didn't really revert - the version on release01x01 adds (dot) to the path, while the "reverted" trunk version uses __FILE__ which does not work on suexec versions of apache. At least the dot in the path works.

Copied the scripts from release01x01 to trunk.

-- GeorgeClark - 09 May 2011

I didn't do the revert. I restored the . to @INC - but only if the split of __FILE__ doesn't return a path. So systems with a usable __FILE__ will still avoid the . in the INC path.

-- GeorgeClark - 09 May 2011

I saw both versions differed, but I didn't remember why. Thanks George for checking and fixing.

-- OlivierRaginel - 09 May 2011

Sorry, I don't understand why this bug it waiting for me. George's fix looks great, and if it's working, then just close this task. Why do I have to vouch for it? I wrote the code which broke this all up in the first place

-- OlivierRaginel - 14 May 2011

Okay - closing. Just wanted to make sure that you liked my fix. Although should this fix also get copied to release branch?

-- GeorgeClark - 14 May 2011

Commenting is disabled while not logged in