Re: OT: Bash Scripting Question
On Monday 11 April 2005 03:36 am, Ron Johnson wrote:
> 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.
If you're including grep, it seems to me if ls were extended to a logical
conclusion of doing one thing and doing it well (listing directories,
including dealing with recursion, it would include the ability to include
pathnames with the filenames (concatenated, lest I be misunderstood again).
Then, if you look at grep as well, it seems find is duplicating what either
is or should be in ls and grep.
I also noticed that neither find or grep are listed as part of the core utils.
I'm surprised this issue hasn't come up often before -- someone wanting to
use shell scripts with ls to perform functions on files in a recursive
listing. In that case, if you're counting on what's in the core utils, it'd
be hard to do something like that.
And, while we're discussing grep -- it raises a question I might as well ask
here. Since grep will search for expressions, is there a similar command
that can do a search and replace in files without the need for a Perl or
Python script? (Just thought I'd ask.)
Hal
Reply to: