Re: OT: Bash Scripting Question
On Sun, Apr 10, 2005 at 02:47:00PM -0400, Hal Vaughan wrote:
> 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.
The example used "$(ls -1)" NOT "$(ls -l)". That's the digit one, not
the letter ell.
What in the world is "l$" supposed to mean?
> 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.
Define "full pathname". The same file can have multiple "full
pathnames". That's what hard links give you. If you want a "full
pathname" you have to *tell* ls what it is.
ls -d /x/y/z/*
will give you
/x/y/z/a
/x/y/z/b
/x/y/z/c
/x/y/z/d
/x/y/z/e
etc.
--
"Learning is like rowing upstream: not to advance is to drop back."
-- Chinese proverb
Rick Pasotto rick@niof.net http://www.niof.net
Reply to: