Adam writes: >Which brings me to my point: find.pl REALLY likes $_ (a personal bane of >mine), so I would advice all you perlers out there to save then restore the >value of $_ in all you wanted scripts. In perl, local() will also do what you want, and you don't even have to explicityly restore it, it will be restored at the end of the current block. sub wanted { local $_; # protect callers variables. &dofile($name) if -f $name && &checkfiletype($name); } I agree in something like find.pl the calling functions should try to do a better job of saving their context when calling a potentially hostile (or at least buggy) wanted().In general though, I feel that it is the subroutine itself that should ensure that it does not change any variables of its caller. (You use local() or my() on all of the other variables so that their names don't conflict with other subroutines, why should your subroutine think it can arbitrarily change $_. Now that I think of it, the interface in find.pl is just poor anyway. Why isn't the information that is passed in $_, $name, and $dir passed via the @_ argument list? At first I was thinking that it was a backwards compatiblity thing, since earlier perls did not have local() or my(). But even that doesn't quite sound write because @_ has always existed. -- Andrew Langmead