On Thu, Dec 06, 2007 at 11:47:53AM -0600, Kyle Wheeler wrote:
> On Thursday, December 6 at 11:40 AM, quoth Paul Hoffman:
> >> chmod a-w dir/new
> >> if [ `find dir -type f` ] ; then
> >
> > You have to do something like this instead:
> >
> > found=`find dir -type f`
> > if -n "$found" ; then
> >
> > At least on my system (Mac OS X 10.3 = Darwin 7.9.0), where find(1)
> > exits with status 0 even if nothing is found.
>
> That's why I used the form that I used. Consider what I said; I said
>
> if [ `find dir -type f` ] ; then
>
> I did not say:
>
> if find dir -type f ; then
>
> The reason is because the former relies on the output of find, and the
> latter relies on the exit status of find. In other words, I had
> already addressed this issue.
Right, sorry. I was going to say to use the exit status of find(1), but
then realized that wouldn't help.
> At worst, some shells might require that
> to be rewritten like this:
>
> if [ "$( find dir -type f )" ] ; then
Or using backticks:
if [ "`find dir -type f`" ]; then
I don't know if that's any more portable, though.
> The reason for that is that [ (also known as /bin/test, and frequently
> a builtin shell command) returns true if it has any arguments of any
> non-zero length, and returns false if it does not (i.e. the -n
> argument is the default behavior).
Thanks -- I didn't know that.
> My example is equivalent to this:
>
> found=`find dir -type f`
> if [ "$found" ] ; then
>
> ...but does not require the extraneous variable definition.
Hmm, my test (builtin, bash 2.05b.0) can't be relied upon:
$ PS1='\n\$ '
$ mkdir foo; cd foo
/User/nkuitse/dt/foo
$ builtin test `find . -type f` || echo No files
OK --> No files
$ touch bar
$ builtin test `find . -type f` || echo No files
OK -->
$ touch baz
$ builtin test `find . -type f` || echo No files
bash: test: ./bar: unary operator expected
Oops! --> No files
/bin/test messes up in the same way, just with a different error
message. YMMV of course.
> ~Kyle
Paul.
--
Paul Hoffman <[EMAIL PROTECTED]>
