caching of path searches [rt.cpan.org #57393]

[toddr]

Migrated from https://rt.cpan.org/Ticket/Display.html?id=57393 (status was 'open')

Tue May 11 18:06:47 2010 user42@zip.com.au - Ticket created
Date: Wed, 12 May 2010 08:06:16 +1000
From: Kevin Ryde user42@zip.com.au

In a test script I tried changing $PATH so as to exercise some code
using IPC::Run with a program found or not found. I had to dig around
to realize IPC::Run caches a found executable.

I think there's probably no need to cache, or only as an option, instead
just execlp each time. If caching then there should be some way to
purge the cache, like the shell "rehash", for when you know or suspect
the target might change, such as when setting a new $PATH.

On Tue May 11 18:06:47 2010, user42@zip.com.au wrote:

I've just hit this as well - it also seems to cache not finding an executable as well. So..., thanks for registering the bug - saved me time poking around, and I agree it would be useful to give control to the developer using this module.

DavidJ

[toddr]

It would be helpful to have a example script or test for this.

[LordAro]

I've just run into this. Sorely need a way of disabling or resetting the cache, especially as there doesn't really seem to be any possible workaround, as %cmd_cache is just a variable, I can't stub it out or anything... Unless anyone knows any better?

Test script:

use strict;
use warnings;

use IPC::Run;

mkdir 'path1';
my $filename1 = 'path1/test.sh';
open(my $fh1, '>', $filename1) or die "Could not open file '$filename1' $!";
print $fh1 "echo 'I am in path1!'";
close $fh1;
chmod 0755, $filename1;

mkdir 'path2';
my $filename2 = 'path2/test.sh';
open(my $fh2, '>', $filename2) or die "Could not open file '$filename2' $!";
print $fh2 "echo 'I am in path2!'";
close $fh2;
chmod 0755, $filename2;

$ENV{PATH} = "path1:$ENV{PATH}";
IPC::Run::run(["test.sh"]); # call directly, not via shell

$ENV{PATH} = "path2:$ENV{PATH}";
IPC::Run::run(["test.sh"]); # wrong exe called :(

# Be nice
unlink 'path1/test.sh';
unlink 'path2/test.sh';
rmdir 'path1';
rmdir 'path2';

And the output showing the bug:

I am in path1!
I am in path1!

with IPCRUNDEBUG=1, we can see what it's doing:

IPC::Run 0000 [#1(289301)]: ****** harnessing *****
IPC::Run 0000 [#1(289301)]: parsing [ 'test.sh' ]
IPC::Run 0000 [#1(289301)]: ** starting
IPC::Run 0000 [#1(289302) test.sh]: execing path1/test.sh
IPC::Run 0000 [#1(289301)]: ** finishing
I am in path1!
IPC::Run 0000 [#1(289301)]: kid 1 (289302) exited
IPC::Run 0000 [#1(289301)]: 289302 returned 0
IPC::Run 0000 [#2(289301)]: ****** harnessing *****
IPC::Run 0000 [#2(289301)]: parsing [ 'test.sh' ]
IPC::Run 0000 [#2(289301)]: ** starting
IPC::Run 0000 [#2(289301)]: 'test.sh' found in cache: 'path1/test.sh'
IPC::Run 0000 [#2(289303) test.sh]: execing path1/test.sh
IPC::Run 0000 [#2(289301)]: ** finishing
I am in path1!
IPC::Run 0000 [#2(289301)]: kid 1 (289303) exited
IPC::Run 0000 [#2(289301)]: 289303 returned 0

(at the very least, thank you very much for such useful debug messaging. God knows how long I'd have been debugging what was going on without it...)

[LordAro]

As a workaround, I'm forcing the module to be reloaded

delete $INC{'IPC/Run.pm'};
require IPC::Run;
IPC::Run->import;

It's horrendous, but does seem to work for this particular issue...