Ron Johnson wrote:
> Hmmm.
> for f in $(ls -1)
> do
> blah ${f}
> done
> It's not exactly like find(1), and it's not as efficient, but it's
> Close Enough.
C'mon, Ron, I know you know that isn't even remotely "close enough" to
find. I mean it doesn't even do the simpliest use of find that I commonly
use. For example
find . -mmin -60
"Find all files in this directory and below which have been modified in
the past 60 minutes." Very useful when you think something is touching files
that aught not be touched or you're looking to find what files were touched so
you can do a quick and dirty backup.
find . -mtime +7 -name \*~
"Find all files older than a week." Great for culling old backups.
The above does neither of those, nor any of the more complex stuff (how
about files modified in the past 10 days, accessed in the past 5, not on a
remote volume and are true files, not links or directories?) as all the logic
is contained in blah() and not ls itself.
Finally, as we have found out in this entire thread. ls -1 is not
equivolant to find . -print. This is easily tested.
for f in (ls -1)
do
rm {$f}
done
Doesn't work as there is no path appended to the filename. More logic for
the blah subroutine, eh? ;P
> The point is is that these are the tools given to us by coreutils.
> I.e., they are what the GNU coreutils maintainers have decided to
> give to us.
> Just like what you said other OS writers do to it's users.
Quite so. Do me a favor, compare the toolkits and come back when you find
one which is more robust and provides as many options.
> 3rd party utility. How broadly do you define that? C/C++, or the
> Windows ports of, for example, Python or Perl?
Those would be third party as they are not included in the base
distribution. Most people overlook how nice the shell can be. Personally I
wouldn't code in shell if forced by threat of death by rabid dogs. Point is
you have the option which is not the case with Redmond's OSes.
> I'm saying that "pass a list of file names to some external app"
> should be given some other name besides "find".
(Un)fortunately that is what it was given so many years ago. Just like i
and t were dropped from list. Why we ls files but don't fn them is beyond my
comprehension.
> "find" is a very broad word that means "search for".
Quite so. List is also a broad which which means, well, list.
> Now is that "search for" a file (as ls also does), or "search for"
> something inside a file?
Now is that "list" a series of files or "list" as series of lines inside a
file? Ya starting to get the problem here?
Besides, just to state it again. ls does not find files. ls lists files.
The shell is what is giving ls the list of files for it to list. Don't
believe me?
{grey@mania:~/t} ls \*
ls: *: No such file or directory
ls does no globbing on it's own. It is the shell's globbing which passes
the file list to ls which in turn lists them out in the requested format.
You'll note this is different from find's behavior.
{grey@mania:~/t} find . -name \*
./bar
./foo
Find found files matching that pattern. List either displays all files in
a directory passed to it, lists the filenames passed to it by the shells
globbing or the current directory if passed nothing at all. I may optionally
do a recursive list of any of the above which are directories. But finding,
nope, none of that here. Which is why when one wants a rather complex method
of listing files one would first have to find the files to list them. ;)
> But then, complaints that Unix utility names are cryptic is nothing
> new.
Only because people aren't thinking too deeply about the complaints they
are lodging. :D
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
Attachment:
signature.asc
Description: OpenPGP digital signature