Re: find printing full paths

[The Wanderer]

(I'm not entirely certain this still belongs on both lists... but I'm
also not sure that it doesn't.)

Bob Proulx wrote:

> The Wanderer wrote:
>
> > What I was doing at the time, so far as I remember, was:
> >
> > for i in `ls path/to/directory1/ path/to/directory2/` ; do ls -l $i 
> > && <complex operation I don't care to reproduce here> $i ; done
> >
> > but that didn't work because the filename printed by the subshell
> > did not exist in the present directory.
>
> Would this have worked there?  I think it is basically the same
> thing.  But avoids the extra ls process and uses the shell directly
> to list the directory.
>
>   for i in path/to/directory1/* path/to/directory2/* ; do
>     ls -l $i && <complex operation> $i
>   done

...y'know, that didn't even occur to me - probably because it isn't in
an "argument to be passed to a command", which is the context I'm used
to for shell wildcard expansion. Yes, that would almost certainly have
worked; thank you for the suggestion.

> > If I were attempting to find in the hierarchy beginning at the
> > current directory, that would be fine. However, it is far more
> > common for me to want to find in some hierarchy other than the one
> > I'm currently at the top of,
>
> How about this?
>
>   find $PWD/foo/* $PWD/bar/*
>
> Or:
>
>   find $PWD/{foo,bar}/*

Either of those might well work, although the former is noticeably more
typing than just passing the directories alone and the latter uses a
type of shell expansion I'm not used to thinking in terms of (and, more
importantly, neither is compatible with tab-completion of paths unless I
go back and insert the '$PWD/'s afterwards - which is awkward). Although
not ideal (as I think I mentioned before, convenience issues), this
should still be functional.

--
      The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.