Item10717: Improved bin script code that finds the executable script on the path.
Priority: Urgent
Current State: Closed
Released In: 2.0.0
Target Release: major
Applies To: Engine
Component:
Branches:
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