Personally, I prefer -mr.

...but if the namespace police won't permit that on cpan, it wouldn't matter, because I would simply rename it for local use.

Did you give any thought to depth first -v- breadth first?

It probably wouldn't make any difference at all for most uses. In fact, now I've typed that, the only time it might make a difference is if you were using it to delete files and wanted to also delete the subir if it ended up empty. But that's probably better done with other tools anyway.

The other thought that crossed my mind was I wonder how it would play with the Getopt::short/middle/long/very-very-very-long* modules? I'm not sure when they do there processing of @ARGV? But if the do their processing at BEGIN time, then maybe yours should be done at CHECK time?

Interference with GetOpt* is a good point... Obviously, the only way such a collision could occur is if there were a directory named "--whatever" or "-w", etc. But it's still the sort of thing that shouldn't be allowed to interfere.

More reason, I think, to go with the -MR-type notation... as that would give more control (over when and where) to someone who was writing a script, or other module, but wanted to incorporate the @ARGV-recursion of this module.

Of course, another route would be to make it all under something like RecursiveARGV.pm, and provide a stub r.pm that was just:

use RecursiveARGV;
[download]

Making perl -mr exactly the same as perl -MRecursiveARGV, but allowing people to do more fun stuff in their scripts like:

#!/usr/bin/perl
require RecursiveARGV;

# cleans @ARGV of any switches here,
# leaving only files
GetOpt(...);

# now @ARGV becomes directory-magic
RecursiveARGV->import();
[download]

Update: I changed midstream between referring to a more full-fledged module as R.pm and RecursiveARGV.pm... and things got a little tangled up.

------------
:Wq
Not an editor command: Wq
[download]

I think that sam has a good point. This would make a good script, but I disagree that it wouldn't make a good module. As it stands now, with all the work being done in import and with @ARGV, it is not really reusable outside of the command line scenario. But if you refactor the code, you could easily make it useable in other scenarios as well. Allowing arguments other than through @ARGV and making import check its execution context before it does any magic would increase the usefulness of this module immensly.

And then package the script in your CPAN distribution, and you get the best of both worlds. This too would allow you to name the module better, as R is incredibly un-descriptive and tells me absolutely nothing about what it does.

Basically I think that you have some good things going here, and to restrict its usefulness to one scenario would be a waste of your effort.

But why is it bad that it is only useful from a command-line scenario? Why does it have to be extended? It seems perfectly designed for what it would be most useful for.

But why is it bad that it is only useful from a command-line scenario?

It's not that it is bad, its that it could be useful in many other scenarios too, so why restrict it? Processing directories recursively is something i run into quite often actually, and not always on the command line. If he could offer a module interface to it as well, I know I would find it alot more useful. But hey, this is all just my opinion.

- stvn

Maybe call it 'pgrep'? Or 'prep'?

-sam

Well, the reason that I'd want to use it as a module (really, even, making it a module is just an end-around run at making it a command line option to the perl interpretter), is because you could use it for anything that puts files on the command line.

The thing about making it a script is that, sure, you can use it to work like grep... but greping files is just the beginning of the potential for this. Any command or script you have that expects files in @ARGV could benefit from this. I know that I, myself, do a lot of stuff that fits that bill.

Imagine, for example, some script perl validate_files.pl [file1] [file2] ..., (whatever validate_files.pl might be): wouldn't it be nice to be able to say: "perl -mr validate_files.pl *"? Or, for that matter, since it is a module, you could incorporate it into validate_files.pl, activated by a "-r " switch.

------------
:Wq
Not an editor command: Wq
[download]

I find that tools like 'find' tend to be a PITA with arbitrary regexen -- something like this would be something I would use a lot.