jik@athena.mit.edu (Jonathan I. Kamens) (03/28/91)
In article <126507@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes:
Otherwise, First pick all the files matching this pattern, then process them.
find ~ -name "*.rm.*.*" -print | maybe-remove
Of course now you have to write the latter program.
A good language to write it in would be perl.
If maybe-remove is written in perl, then it is ridiculous to do the
find in a separate process, since the perl can do it in the same
process as the maybe-remove stuff.
Doesn't the perl distribution come with "find2perl" or something like
that?
Jonathan Kamens USnail:
MIT Project Athena 11 Ashford Terrace
jik@Athena.MIT.EDU Allston, MA 02134
Office: 617-253-8085 Home: 617-782-0710rbj@uunet.UU.NET (Root Boy Jim) (03/29/91)
In article <JIK.91Mar28001532@pit-manager.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >In article <126507@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: > Otherwise, First pick all the files matching this pattern, then process them. > > find ~ -name "*.rm.*.*" -print | maybe-remove > > Of course now you have to write the latter program. > A good language to write it in would be perl. > >If maybe-remove is written in perl, then it is ridiculous to do the >find in a separate process, since the perl can do it in the same >process as the maybe-remove stuff. I almost said that. However, while it is "possible" to move the find into the script, it is nontrivial to do. Look at the complexity of find2perl to see what I mean. Besides, you have to be smart enuf not to follow symbolic links :-) "Rediculous" is too strong a word. In fact, but for the existence of find2perl, "rediculous not to" is closer to the truth. >Doesn't the perl distribution come with "find2perl" or something like >that? Well, it seems to, but I see no documentation. It may have been posted to this group, but right now I'm too lazy to look for it. However, given the existence of find2perl, one should probably use it. After a careful scan, it seems that it can be used more or less as a replacement for find, plus a few extra niftys, such as eval. There is one thing missing, however; eval looks pretty neat, but can become complicated in a hurry. I would like the ability to load code into the script in order to simplify things. Thus: find2perl ~ -load maybe_remove.pl -name "*.rm.*.*" \ -eval '&maybe_remove($file)' I'm not clear on whether the current filename is in $file, $name, or $_. -- [rbj@uunet 1] stty sane unknown mode: sane
merlyn@iwarp.intel.com (Randal L. Schwartz) (03/29/91)
In article <126658@uunet.UU.NET>, rbj@uunet (Root Boy Jim) writes: | There is one thing missing, however; eval looks pretty neat, | but can become complicated in a hurry. I would like the ability | to load code into the script in order to simplify things. Thus: | | find2perl ~ -load maybe_remove.pl -name "*.rm.*.*" \ | -eval '&maybe_remove($file)' | | I'm not clear on whether the current filename is in | $file, $name, or $_. find2perl $HOME -name '*.rm.*.*' -eval '&maybe_remove($name)' | \ (cat maybe-remove.pl - ) | perl (although having a -load would be nicer. :-) print "Just another Perl hacker," -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\ | on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn | \=Cute Quote: "Intel: putting the 'backward' in 'backward compatible'..."====/
composer@chem.bu.edu (Jeff Kellem) (03/29/91)
In article <126658@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: > However, while it is "possible" to move the find into the script, it is > nontrivial to do. Look at the complexity of find2perl to see what I mean. I just glanced over find2perl again; doesn't look too complex. :) It's just implementing what find does. The most "complex" part about find2perl may just be that it generates a perl script.. (?) Of course, maybe you're considering the cpio/tar writing that's done inside the perl script? But, also generating the perl script doesn't seem that complex to me either..maybe it's just my twisted mind. ;-) It looks like Larry has find2perl attempt to produce readable code, too. Wasn't that nice... :) > Well, it seems to, but I see no documentation. It may have been > posted to this group, but right now I'm too lazy to look for it. Yep, it was posted to c.l.p a couple times. But, there was (of course) little documentation. There's always the source, right? ;-) > There is one thing missing, however; eval looks pretty neat, > but can become complicated in a hurry. I would like the ability > to load code into the script in order to simplify things. Thus: > > find2perl ~ -load maybe_remove.pl -name "*.rm.*.*" \ > -eval '&maybe_remove($file)' That shouldn't be too hard to add. Let's see.. maybe add something similar to this (definitely untested) with the list of 'elsif's near "elsif ($_ eq 'name') {" ? elsif ($_ eq 'load') { die "-load must have a filename argument\n" unless @ARGV; $initload .= 'require "' . shift . qq{";\n}; next; } and add the following line before the first "if ($initls) {" line: print $initload, "\n" if $initload; That should do it, I hope. No checks are made that the filename in '-load filename' (maybe that should be -require?) really exists. If ya want to add it, go ahead. :-) > I'm not clear on whether the current filename is in > $file, $name, or $_. It looks like the current filename is in $name. There may be a place where Larry left a $_ and meant $name in the code; but it also probably doesn't make a difference in that case. I'll have to look at it a little more closely to make sure; I've only had time to glance at it. Cheers... -jeff Jeff Kellem Internet: composer@chem.bu.edu
lwall@jpl-devvax.jpl.nasa.gov (Larry Wall) (03/29/91)
In article <COMPOSER.91Mar28231915@chem.bu.edu> composer@chem.bu.edu writes:
: It looks like the current filename is in $name. There may be a place
: where Larry left a $_ and meant $name in the code; but it also probably
: doesn't make a difference in that case. I'll have to look at it a little
: more closely to make sure; I've only had time to glance at it.
$name = "$dir/$_";
The current basename is purposefully left in $_ so that -name tests can
match against it easily.
And yes, I put some effort into making the output readable, since one
of the primary reasons for using find2perl is when you want to take
find's semantics as a base and then start customizing the script. s2p,
a2p and find2perl are all intended to be translators, not just compilers.
Code migration is really the primary issue. That, and brain migration.
Larryallbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/05/91)
As quoted from <126658@uunet.UU.NET> by rbj@uunet.UU.NET (Root Boy Jim): +--------------- | find into the script, it is nontrivial to do. Look at the | complexity of find2perl to see what I mean. Besides, you | have to be smart enuf not to follow symbolic links :-) +--------------- I'll get find.pl out after I clean up a few minor remaining problems (i.e. how to do glob matches on strings, as opposed to file names...). I may even post it without that if I can't figure it out (you'll have to use -name_re instead of -name, though). It's not particularly complex if you ignore the list-of- lists stuff. I can't help it that Jim's on one of those systems where you have to use symlinks in dangerous ways merely in order to survive [ :-) ] but I'll have the default symlink traversal flag configurable (that is, aside from the predicates themselves). +--------------- | There is one thing missing, however; eval looks pretty neat, | but can become complicated in a hurry. I would like the ability | to load code into the script in order to simplify things. Thus: | | find2perl ~ -load maybe_remove.pl -name "*.rm.*.*" \ | -eval '&maybe_remove($file)' +--------------- find.pl has -load. And -eval. And -okeval. +--------------- | I'm not clear on whether the current filename is in | $file, $name, or $_. +--------------- find.pl puts it in $_ for consistency with everything else. Also, user code (from -load with no package, -eval, etc.) is in a separate package from the actual find routines, so there's a lower chance of conflict. (The find package has a slightly odd name, too, to avoid problems.) ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 2m, 220, 440, 1200 Internet: allbery@NCoast.ORG (QRT on HF until local problems fixed) America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
rbj@uunet.UU.NET (Root Boy Jim) (04/06/91)
In article <1991Apr5.001508.16154@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/AA) writes:
?As quoted from <126658@uunet.UU.NET> by rbj@uunet.UU.NET (Root Boy Jim):
?+---------------
?| Besides, you have to be smart enuf not to follow symbolic links :-)
?+---------------
?
?I can't help it that Jim's on one of those systems where you have to use
?symlinks in dangerous ways merely in order to survive [ :-) ] but I'll have
?the default symlink traversal flag configurable (that is, aside from the
?predicates themselves).
This is not funny anymore. You know damn well what kind of system
we have. SYMLINKS ARE NOT TO BE TRAVERSED BY DEFAULT. Ignore for the
moment that it's the correct thing to do, and consider that it is
the standard way of doing thing is real BSD derived UNIX. The
fact that other people, notably the toys that Brandon seems to be
stuck with, do it differently merely attests to their ignorance.
--
[rbj@uunet 1] stty sane
unknown mode: sane