On Sun, 2005-04-10 at 22:10 -0500, Alex Malinovich wrote: > On Sun, 2005-04-10 at 12:06 -0500, Ron Johnson wrote: > --snip-- > > I'm saying that "pass a list of file names to some external app" > > should be given some other name besides "find". > > > > "find" is a very broad word that means "search for". > > > > Now is that "search for" a file (as ls also does), or "search for" > > something inside a file? > > > > But then, complaints that Unix utility names are cryptic is nothing > > new. > > I might be missing something here, but I really don't see much > functional overlap between ls and find (at least in the way that I use > them). If I want to _FIND_ a file that I know I have SOMEWHERE under my > home (however many levels deep), and I know that the name contains the > letters a, b, and c, I will do a 'find /home/username -iname "*abc*"' > and it will find that file for me. Or locate. "LOCATE the file in /home/username that matches the re *abc*." > If, on the other hand, I want to LIST a file (or series of files) in a > directory that I already know (say my home directory) and I know that > those files start with the characters AbC, I will do a > 'ls /home/username/AbC*'. > > Where's the overlap and conflicting naming here? Those assumptions about what FIND and LIST mean are arbitrarily narrow. For example, "Use grep to FIND all files that match a given re." I whole-heartily agree with Hal that the functionality of ls(1) and find(1) should be merged, and be given a new name. -- ----------------------------------------------------------------- Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "We may not imagine how our lives could be more frustrating and complex--but Congress can." Cullen Hightower
Attachment:
signature.asc
Description: This is a digitally signed message part