Lets break the '.*/*' approach down a bit, to help you understand the difference between the two
perl -pie 's/old/new/g' ./*/*
The first thing that happens when you enter this command
into your shell, is that the shell expands the wildcards.
This is important.... perl doesn't ever see the './*/*' construct. The shell then executes the expanded command
which now looks like:
perl -pie 's/old/new/g' subdir/file1 subdir/file2 subdir2/file1 subdir
+2/subsubdir/
And perl does its magic inplace editing on this list of
files. (note, see the update to my previous post) No recursion is done. You've simply said, execute this perl command on the following files. Those files being ones that the shell matched with its './*/*' pattern.
In otherwords, you could use that command like so:
perl -pi -e 's/old/new/g' file1 dir1/file2 /usr/local/file3 /tmp/*
You've passed the perl command a set of files which it will
work with. (thats what the empty <> operator does that you've seen in the perlrun docs)
On the other hand, the find solution will walk the filesystem executing the perl command on each file that
matches its criteria (here its just </code>-type f</code>
which means a regular file) Depending on your filesystem layout, this can be much more powerful than the other solution.
Said another way... the find solution is equivalent to
the following series of commands:
perl -pie 's/old/new/g' ./*
perl -pie 's/old/new/g' ./*/*
perl -pie 's/old/new/g' ./*/*/*
perl -pie 's/old/new/g' ./*/*/*/*
perl -pie 's/old/new/g' ./*/*/*/*/*
etc.....
Of course you'll get errors about executing the command on directories, and you'll soon hit your shells 'too many arguments' limit. Therefore find is a better general solution, but './*/*' might work fine in any one instance.
-Blake |