Re: OT: Bash Scripting Question
On Sunday 10 April 2005 01:06 pm, Ron Johnson wrote:
> On Sun, 2005-04-10 at 05:59 -0700, Steve Lamb wrote:
> > Ron Johnson wrote:
> > > Your next paragraph contradicts this sentence.
> >
> > It doesn't.
> >
> > > And the GNU coreutils maintainers make you do things the way they
> > > think things should be done.
> >
> > Nope. Several examples were provided, not just one. Also one
> > explination was provided which explains why find is used. You are
> > finding these files. The thing is you're using an overly broad statement
> > which happens to include all the files in a given path. You'll note,
> > however, that find does not replicate the functionality of ls. It does
> > not list all the file's attributes (name, date, mtime, permissions, size
> > and so on) only the filename itself for another tool... say... ls to use
> > to obtain that information.
>
> Hmmm.
> for f in $(ls -1)
> do
> blah ${f}
> done
If you change the "for f in $(ls -l)" to "for f in $(ls -l$)", it won't work.
I don't feel I'm an expert, but from my layman's understanding of *nix, that
each command does one thing and does it well, it seems there should be two
switches on ls to allow it to print the FULL pathname, or the relative
pathname of a file in either a regular or recursive listing. If I knew C,
and had the time, I'd add one myself, but from what I understand, ls is part
of the bash shell (which ls gives no response), and I don't want to get into
that.
I also wouldn't know how to submit such a patch for potential inclusion, but
it seems to me that is a weakness in the command.
>
> It's not exactly like find(1), and it's not as efficient, but it's
> Close Enough.
>
> 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.
>
> > > Unless, as with every OS, you write your own utility.
> >
> > Incorrect. I charge you to attempt to write a basic find utility
> > which does the requested action in Win95, 98, NT, 2k, without using the
> > provided utility (LOCATE, I believe) and without using a third party
> > solution for any step. Batch, AFAIK, is not up to the task. :P
>
> 3rd party utility. How broadly do you define that? C/C++, or the
> Windows ports of, for example, Python or Perl?
>
> > Finally I am wondering why you're railing against GNU core tools when
> > they are just a replication and extension of the older unix core tools.
> > I've certainly used find on non-GNU systems.
>
> I'm not *railing* against them.
>
> I'm saying that "pass a list of file names to some external app"
> should be given some other name besides "find".
I have to agree with that (and there you have it -- the apocalypse is coming,
now that I've agreed with Ron).
> "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.
It seems to me if the job of ls is to list files in a directory (or a
recursive directory tree), if it is unable to provide the full pathname, it
is lacking in that ability. It's great that find does the job, but it seems
that the logical place to look for a listing of files in a directory is ls,
not find.
Hal
Reply to: