Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

RFC: new module r (or R)

by etcshadow (Priest)
on Mar 05, 2004 at 18:08 UTC ( #334305=perlmeditation: print w/ replies, xml ) Need Help??

Hello, all. In response to this node, I decided to finallize and publish something I've been working on... a module that replaces directories in @ARGV with their contents, recursively (by tieing @ARGV, and traversing directories as they are accessed). The idea is (obviously) that a user could type:
perl -mr -ne 'print if /foo/' *
and get the same behavior as from
grep -r foo *
Anyway, the thing that I'm offering for comment is basically, should I make it -mr or make it -MR? (And also, of course, if anyone has a reasonable reason why I'd be on crack to even do this, or that it's already been done in a useful enough manner.) The obvious implication being that the tie @ARGV,... occurs either in file-scope or in the import method... which is a miniscule code change, that I'd be happy to make before offering this up to CPAN.

My reasons for wanting to use -mr over -MR are perhaps silly, but quite frankly:

  • it saves a keystroke (the shift key)
  • it is mostly going to be used with other lower-case switches (-p, -n, -e, -i, -l)
  • it's a closer syntax to its closest cousin, grep -r
I think those are all valid things to consider, since we're talking about what effectively amounts to a command line switch.

The costs, however, are that:

  • a lowercase module name implies that it is a pragma... and this is only sort of like a pragma (but not really)
  • it won't work quite like a normal module, being use'd, because the magic occurs when the file is required, without anything happen at import time
I think it's obvious that the m and r should be in the same case, as perl -mR -e ... or perl -Mr -e ... are just shift-key gymnastics that nobody wants or should have to go through.

Thoughts? Comments? Also, is there a more definitive place to take this question, like comp.lang.something-or-other?

------------ :Wq Not an editor command: Wq

Comment on RFC: new module r (or R)
Select or Download Code
Re: RFC: new module r (or R)
by samtregar (Abbot) on Mar 05, 2004 at 18:26 UTC
    This sounds useful, but I think I'd prefer it packaged as a script. My reasoning is that modules are for reusable code on a large scale, but scripts are the right size for small-scale reusability like this.

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


      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 [file1] [file2] ..., (whatever might be): wouldn't it be nice to be able to say: "perl -mr *"? Or, for that matter, since it is a module, you could incorporate it into, activated by a "-r " switch.

      ------------ :Wq Not an editor command: Wq
Re: RFC: new module r (or R)
by stvn (Monsignor) on Mar 05, 2004 at 18:52 UTC

    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
Re: RFC: new module r (or R)
by BrowserUk (Pope) on Mar 05, 2004 at 18:54 UTC

    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?

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
      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, and provide a stub that was just:

      use RecursiveARGV;
      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();

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

      ------------ :Wq Not an editor command: Wq
Re: RFC: new module r (or R)
by flyingmoose (Priest) on Mar 05, 2004 at 19:57 UTC
    The use of a module to simulate a switch is really clever here. Does CPAN object to one char packages? I rather like the idea.

    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.

Re: RFC: new module r (or R)
by perrin (Chancellor) on Mar 05, 2004 at 20:39 UTC
    I think it should be something like -MRecurse. Why? Because it's confusing when you make things look like something they're not. It's not a perl switch, or a pragma, and making it look like one will only confuse your users.
Re: RFC: new module r (or R)
by BUU (Prior) on Mar 05, 2004 at 21:35 UTC
    Isn't it (mostly) like a pragma anyways, and thus deserving a one character name? My logic basically goes like: strict is a pragma, it modifies how perl feels about non-lexical values. r is a pragma, it modifies how perl feels about @ARGV.

    Maybe I'm reaching, but anyways, I'd like to throw my vote in for r or R, preferably so I can use it to replace find (it scares me!).

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://334305]
Approved by gmax
Front-paged by Courage
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2014-07-11 22:28 GMT
Find Nodes?
    Voting Booth?

    When choosing user names for websites, I prefer to use:

    Results (235 votes), past polls