in reply to Read all the file path having text document

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.

Replies are listed 'Best First'.
Re^2: Read all the file path having text document
by AnomalousMonk (Archbishop) on Nov 29, 2008 at 23:27 UTC
    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]
[reply]
[d/l]

      No prototype, no warning.

      Perl's payment curve coincides with its learning curve.
[reply]
        No prototype, no warning.
        Did you mean to convey that simply omitting the prototype from the predeclaration would suppress the warning? 
        >perl -wMstrict -le
"sub S;
 S('foo');
 sub S ($) { print $_[0], '-totyped subroutine' };
"
foo-totyped subroutine

        [download]
        I was rather surprised to find that this worked! Can you point me to an explanation of why this works as it does?

        In any event, I continue to agree it is best to avoid prototyping both in the OPed code and in general.

[reply]
[d/l]
Re^2: Read all the file path having text document
by Wiggins (Hermit) on Nov 30, 2008 at 14:59 UTC
    "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?

[reply]
      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?"
[reply]
        Ok ... Perl prototypes are really "context casts", and that seems dangerous ( I will be commenting out all of mine). Not the 'prototype' that the software industry has been using for the last 30 years, across hundreds of languages. But, I do hope that 'addition' is a mathematical operation and not a name for shuffling of the bits with truncation of the overflows.

        Bad re-use of nomenclature.

        EOM

[reply]
[reply]

In Section Seekers of Perl Wisdom