Re: scary and strange thing in FindBin

[Todd Rinaldo]

On Sun, Aug 10, 2008 at 9:30 PM, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote:
> * Graham Barr <[EMAIL PROTECTED]> [2008-08-11 03:05]:
>> On Aug 9, 2008, at 8:38 PM, Aristotle Pagaltzis wrote:
>>> * Todd Rinaldo <[EMAIL PROTECTED]> [2008-08-10 03:35]:
 What alternatives do you recommend?
>>>
>>> See Tom Heady's reply on this thread.
>>
>> Which also as issues, albeit maybe fewer.
>
> Yes, it will fail in some very rare cases.
>
> However, it does so loudly and predictably.
>
> In contrast, FindBin tries to avoid failing by employing
> heuristics, and as we all know that is a fancy word for saying
> "it doesn't work." Unsurprisingly, when it fails, it fails
> silently with bizarre results – as it did for Gabor.
>
> Both failure modes are very rare, which means FindBin almost
> never needs to fall back on heuristics, which is why people tend
> to think I'm just nitpicking when I point out that it's broken as
> designed and should not be used. But I dislike software that can
> fail silently with bizarre results as a matter of principle. And
> when the heuristic is there to catch an almost irrelevant failure
> mode, its extremely disproportionate surprise potential just
> isn't worth it, IMO.
>
>> IIRC when FindBin was written there were some system where $0
>> was not a full path when the script was invoked via PATH, which
>> was why FindBin was implemented to do the PATH search. But that
>> was over a decade ago and I cannot remember which OS it was on,
>> so who knows if it is still in use today.
>
> I guess it might make some sense under those circumstances. But
> in that case it should have done the PATH search only on affected
> platforms, not everywhere. (Ideally it would specifically probe,
> if possible in any way, for whether the heuristic was needed.)
>
> Anyway, shoulda coulda woulda… that horse has long left the barn.


It sounds like there's a good case here for defaulting this off and
making path searching an option.

Re: scary and strange thing in FindBin

[Eric Wilhelm]

# from Aristotle Pagaltzis
# on Sunday 10 August 2008 19:30:

>>> See Tom Heady’s reply on this thread.
>>
>> Which also as issues, albeit maybe fewer.
>
>Yes, it will fail in some very rare cases. However, it does so loudly
>and predictably. 

Oh?  'chdir dirname( rel2abs( $0 ) );' doesn't look to me to contain the 
loud and predictable 'or die'

>FindBin tries to avoid failing by employing
>heuristics, and as we all know that is a fancy word for saying
>“it doesn’t work.”

I guess we like to call it a heuristic, because that makes it sound like 
we're solving some complicated and mathematically difficult problem?
But "mistake" has fewer letters and doesn't imply that locating a 
directory somehow requires the Ramsey number for red six and blue six.

In the case of Makefile.PL wanting to know where it is, I think anything 
involving rel2abs is probably overkill, and $0 could quite likely be 
incorrect on account of do(), so all you really want is 
dirname(__FILE__), right?  Of course, if you're going to go through the 
loop of resolving symlinks, you do need to deal with things having been 
relative (assuming of course that what you wanted was to know the 
location of the file at the end of whatever number of symlinks (and 
that you didn't mind if a hardlink was involved because then we have to 
run find on the entire partition and compare inodes (which clearly 
FindBin should have done (but probably several steps after it 
checked -e $0, which it did not (but that would have been a nifty first 
step.)

But in this particular case, does everything else in the world not 
already explode anyway unless(-e './Makefile.PL')?

As for solving the generic case, you still have to account for PAR, and 
the fact that $0 might be '-e', or could simply be relative to wherever 
we were before a chdir(), at which point we should probably just 
exec('/usr/bin/eject', '.') in order to achieve suitable predictable 
loudness.

But yes, the FindBin code is wrong, and so is the documentation.

  "If perl is invoked as C and I does not have
  executable rights and a program called I exists in the users
  C<$ENV{PATH}> which satisfies both B<-x> and B<-T> then FindBin
  assumes that it was invoked via the C<$ENV{PATH}>."

Should have just said: "if $0 !~ m#/# and a program called ..."

It seems like something using import() and caller() might generate a 
more predictable solution with fewer caveats (such as hating to be 
called twice, assuming $0, etc.)  It could possibly even defer the 
symlink resolution bit until it was actually needed.

  use File::WhereAmI;
  my $where = File::WhereAmI->real_directory;
  my $there = File::WhereAmI->where_is_who("Bar.pm")->filename;


But in Makefile.PL land, all of the necessary simplifying assumptions 
were made long ago.

  $ cd /tmp
  $ perl /wherever/Makefile.PL
Could not open 'lib/Foo.pm':
  No such file or directory at .../ExtUtils/MM_Unix.pm line 2708.

--Eric
-- 
"Unthinking respect for authority is the greatest enemy of truth."
--Albert Einstein
---
http://scratchcomputing.com
---

Re: scary and strange thing in FindBin

[Aristotle Pagaltzis]

* Graham Barr <[EMAIL PROTECTED]> [2008-08-11 03:05]:
> On Aug 9, 2008, at 8:38 PM, Aristotle Pagaltzis wrote:
>> * Todd Rinaldo <[EMAIL PROTECTED]> [2008-08-10 03:35]:
>>> What alternatives do you recommend?
>>
>> See Tom Heady’s reply on this thread.
>
> Which also as issues, albeit maybe fewer.

Yes, it will fail in some very rare cases.

However, it does so loudly and predictably.

In contrast, FindBin tries to avoid failing by employing
heuristics, and as we all know that is a fancy word for saying
“it doesn’t work.” Unsurprisingly, when it fails, it fails
silently with bizarre results – as it did for Gabor.

Both failure modes are very rare, which means FindBin almost
never needs to fall back on heuristics, which is why people tend
to think I’m just nitpicking when I point out that it’s broken as
designed and should not be used. But I dislike software that can
fail silently with bizarre results as a matter of principle. And
when the heuristic is there to catch an almost irrelevant failure
mode, its extremely disproportionate surprise potential just
isn’t worth it, IMO.

> IIRC when FindBin was written there were some system where $0
> was not a full path when the script was invoked via PATH, which
> was why FindBin was implemented to do the PATH search. But that
> was over a decade ago and I cannot remember which OS it was on,
> so who knows if it is still in use today.

I guess it might make some sense under those circumstances. But
in that case it should have done the PATH search only on affected
platforms, not everywhere. (Ideally it would specifically probe,
if possible in any way, for whether the heuristic was needed.)

Anyway, shoulda coulda woulda… that horse has long left the barn.

Regards,
-- 
Aristotle Pagaltzis // 

Re: scary and strange thing in FindBin

[Graham Barr]

On Aug 9, 2008, at 8:38 PM, Aristotle Pagaltzis wrote:


* Todd Rinaldo <[EMAIL PROTECTED]> [2008-08-10 03:35]:

What alternatives do you recommend?


See Tom Heady’s reply on this thread.


Which also as issues, albeit maybe fewer.

IIRC when FindBin was written there were some system where $0 was not  
a full path when the script was invoked via PATH, which was why  
FindBin was implemented to do the PATH search. But that was over a  
decade ago and I cannot remember which OS it was on, so who knows if  
it is still in use today.


Graham.

Re: scary and strange thing in FindBin

[Aristotle Pagaltzis]

* Todd Rinaldo <[EMAIL PROTECTED]> [2008-08-10 03:35]:
> What alternatives do you recommend?

See Tom Heady’s reply on this thread.

Regards,
-- 
Aristotle Pagaltzis // 

Re: scary and strange thing in FindBin

[Todd Rinaldo]

On Sat, Aug 9, 2008 at 6:43 AM, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote:
> * Gabor Szabo <[EMAIL PROTECTED]> [2008-08-09 12:15]:
>> If I have the following code in a file called Makefile.PL
>>
>> use FindBin;
>> print "$FindBin::Bin\n";
>>
>> perl Makefile.PL  prints
>>
>> /home/gabor/work/pugs
>>
>> no matter where the file is located.
>
> And whenever I tell people that FindBin is broken and they should
> not use it, they look at me like I told them I'm seeing ghosts.
>
> Regards,
> --
> Aristotle Pagaltzis // 
>
>

Aristotle, What alternatives do you recommend?

Re: scary and strange thing in FindBin

[Tom Heady]

Gabor Szabo wrote:

On Sat, Aug 9, 2008 at 1:22 PM, Paul Johnson <[EMAIL PROTECTED]> wrote:

On Sat, Aug 09, 2008 at 01:09:23PM +0300, Gabor Szabo wrote:

If I have the following code in a file called Makefile.PL

use FindBin;
print "$FindBin::Bin\n";

perl Makefile.PL  prints

/home/gabor/work/pugs

no matter where the file is located.

If the file is called a.pl  with the same content
it prints the correct directory as expected.

perl 5.8.8 on Ubuntu
perl -MFindBin -e'print $FindBin::VERSION'  is 1.47

The only environment variable I can see containing pugs is PATH

I suspect you've fallen foul of the problem documented in the KNOWN BUGS
section of the documentation.


It looks like you are right.
Not so surprisingly I don't have an executable a.pl anywhere in my path but I
have such a Makefile.PL in the pugs directory.

(on more good reason for the CPANTS metric checking for *not* executable
Makefile.PL :-)

This is the reason I could not install CPANPLUS as first thing it does
in Makefile.PL it calls

   chdir $FindBin::Bin



As an alternative:

use File::Spec::Functions 'rel2abs';
use File::Basename 'dirname';

chdir dirname( rel2abs( $0 ) );


Tom

Re: scary and strange thing in FindBin

[Aristotle Pagaltzis]

* Gabor Szabo <[EMAIL PROTECTED]> [2008-08-09 12:15]:
> If I have the following code in a file called Makefile.PL
> 
> use FindBin;
> print "$FindBin::Bin\n";
> 
> perl Makefile.PL  prints
> 
> /home/gabor/work/pugs
> 
> no matter where the file is located.

And whenever I tell people that FindBin is broken and they should
not use it, they look at me like I told them I’m seeing ghosts.

Regards,
-- 
Aristotle Pagaltzis // 

Re: scary and strange thing in FindBin

[Gabor Szabo]

On Sat, Aug 9, 2008 at 1:22 PM, Paul Johnson <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 09, 2008 at 01:09:23PM +0300, Gabor Szabo wrote:
>> If I have the following code in a file called Makefile.PL
>>
>> use FindBin;
>> print "$FindBin::Bin\n";
>>
>> perl Makefile.PL  prints
>>
>> /home/gabor/work/pugs
>>
>> no matter where the file is located.
>>
>> If the file is called a.pl  with the same content
>> it prints the correct directory as expected.
>>
>> perl 5.8.8 on Ubuntu
>> perl -MFindBin -e'print $FindBin::VERSION'  is 1.47
>>
>> The only environment variable I can see containing pugs is PATH
>
> I suspect you've fallen foul of the problem documented in the KNOWN BUGS
> section of the documentation.

It looks like you are right.
Not so surprisingly I don't have an executable a.pl anywhere in my path but I
have such a Makefile.PL in the pugs directory.

(on more good reason for the CPANTS metric checking for *not* executable
Makefile.PL :-)

This is the reason I could not install CPANPLUS as first thing it does
in Makefile.PL it calls

   chdir $FindBin::Bin

thanks
   Gabor

Re: scary and strange thing in FindBin

[Paul Johnson]

On Sat, Aug 09, 2008 at 01:09:23PM +0300, Gabor Szabo wrote:
> If I have the following code in a file called Makefile.PL
> 
> use FindBin;
> print "$FindBin::Bin\n";
> 
> perl Makefile.PL  prints
> 
> /home/gabor/work/pugs
> 
> no matter where the file is located.
> 
> If the file is called a.pl  with the same content
> it prints the correct directory as expected.
> 
> perl 5.8.8 on Ubuntu
> perl -MFindBin -e'print $FindBin::VERSION'  is 1.47
> 
> The only environment variable I can see containing pugs is PATH

I suspect you've fallen foul of the problem documented in the KNOWN BUGS
section of the documentation.

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

scary and strange thing in FindBin

[Gabor Szabo]

If I have the following code in a file called Makefile.PL

use FindBin;
print "$FindBin::Bin\n";

perl Makefile.PL  prints

/home/gabor/work/pugs

no matter where the file is located.

If the file is called a.pl  with the same content
it prints the correct directory as expected.

perl 5.8.8 on Ubuntu
perl -MFindBin -e'print $FindBin::VERSION'  is 1.47

The only environment variable I can see containing pugs is PATH

Gabor