Christian,
I feel this may be 'the stoopid answer' - so bare with me...
On Saturday, April 20, 2002, at 07:21 , [EMAIL PROTECTED]
wrote:
[..]
> With the
>
> find ( { wanted => \&process_file, follow=> 0}, $Dir);
>
> function my program runs through a directory-tree and the
> process_file-function works with the found files.
>
> In my case I want to cut a part from the path of the file (not all).
> At the moment I use global variables to give the process_file function
> the information what to cut. But it's not a nice way, I think.
since you can not get that to say
sub process_file {
my ( $funkyDirFoo , $bit_off_if ) = @_;
my $fullPath = "$File::Find::dir/$_";
if ( /$bit_off_if/ ) {
$fullPath =~ s/$funkyDirFoo//;
}
push(@push_list , $fullPath );
}
to allow the
find ( { wanted => \&process_file(....), follow=> 0}, $Dir);
is there some voodoo to get those variables passed to the call
back function some slicker way????
other than with:
local( $funkyDirFoo , $bit_off_if );
and hence the appropriate use of 'our ($funkyDirFoo , $bit_off_if );'
in the main declaration section....
if you crawl the File::Find with say
perldoc -m File::Find
you will find a line like:
&$wanted_callback;
and since the compiler can only compile the address of the
function - and not the 'address of the function and the
memory location of variables to pass....' you be fragged.
Basically from what I am figuring out - the reason that they
are using the callback system is because it allows you to
'side skip' the problem by having the call back function
more directly in your control to allow the the Name Space
Management game to work around these things...
Notice in mine I just push them onto a list and deal
with it all when the find be done....
But If you find a more effective way to do all of this,
do let me know...
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
