Why not use File::Find::Rule or similar?

my @files = File::Find::Rule->new()
            ->file()
            ->name('*.txt')
            ->in($path);
[download]

If you have a problem with links (symbolic or hard) that point to a parent directory, I don't know if they'll help. What they will do is make your code clearer and save you from reinventing the wheel.

Unless this is primarily for educational purposes, I'd recommend using File::Find or File::Find::Rule instead :)

As to dealing with symlink cycles, see the follow/follow_fast/follow_skip options that File::Find provides.

BTW,

sub recurse($);

in Perl you usually wouldn't use prototypes, unless you have a very good reason. Also, you don't need to predeclare the subroutine here.

I agree that prototyping is unnecessary and potentially very confusing in the OPed code (and in general) and should be avoided, but in the specific code given in the OP, isn't predeclaration of the subroutine necessary – at least to avoid a warning?

>perl -wMstrict -le
"sub S ($);
 S('foo');
 sub S ($) { print $_[0], '-totyped subroutine' };
"
foo-totyped subroutine

>perl -wMstrict -le
"
 S('foo');
 sub S ($) { print $_[0], '-totyped subroutine' };
"
main::S() called too early to check prototype at -e line 1.
foo-totyped subroutine
[download]

No prototype, no warning.

---

Perl's payment curve coincides with its learning curve.

"in Perl you usually wouldn't use prototypes, unless you have a very good reason."

Why? What is the downside? Is there some guidance document somewhere?
I can see that for 'short' scripts (all on a single page); but what about 4000 lines of Perl spread across 10-12 packages?

To me; prototyping keeps me from making subtle design changes (just 1 extra arg, in this special case) that are not documented, and probably will cause maintenance problems later.
I learned to even like C++'s mangled namespace to use argument types as overloading specifiers.

I think it is inappropriate to pooh-pah someone for using good software engineering technique. Are 'strict', 'warning', and maybe 'taint' really not needed either?

To me; prototyping keeps me from making subtle design changes (just 1 extra arg, in this special case) that are not documented, and probably will cause maintenance problems later.

If you're doing that, you don't understand what prototypes do (and this is common, and one of the reasons for the general rule that you shouldn't use them unless you've got a good reason).

Prototypes in perl convert arguments and allow short-cuts in the calling code. The "checking" of the arguments only happens as a side effect, and you'll only get warnings/errors if the arguments cannot get converted. This probably means you'll have subtler bugs, not less.

See also Are prototypes evil?, for example

"What should it profit a man, if he should win a flame war, yet lose his cool?"

... what Joost said.

I'd just like to add two more pointers:

• Gratuitous use of Perl Prototypes
• The purpose of prototypes in perl subroutines

See perlre, particularly the Regular Expressions and /s switch sub-sections.

Hi Monks, Thanks for the help . I completely changed my code and its working , though its taking 4 minutes to get the path of all the text documents. I have a 120 GB hardisk and only 40 GB contains text document. Can I make it faster?Navzit

use File::Find::Rule;
my $rule =  File::Find::Rule->new;
  $rule->file;
  $rule->name( '*.txt' );
  my @files = $rule->in("/" );
  open(W,"> index.txt")|| die "can't open index.txt file";
foreach $files_name (@files)
{
    print W $files_name ;
    print W "\n";
}
[download]

Compare your code to the code produced by find2perl / -type f -iname '*\.txt'

Depending on your computer and disk specs, 4 minutes may not be all that bad.