compressdir bug?

[Michael "Ford" Ditto]

In article <318 at hawkmoon.MN.ORG> det at hawkmoon.MN.ORG (Derek E. Terveer) writes:
>$ test -r /tmp/f;echo $?	#test test  -- seems to work as expected..
>0
>$ find f -type f -links 1 -exec test -r {} \; -print	#should print "f" - no!
 [ It doesn't print "f" ]
 [ ... ]

>So what is going on here?  Now, did I misunderstand something????

Well, you sort-of answer your own question just before:

>$ ls -l /bin/test /usr/bin/test /usr/ubin/test	#check for test commands
>/bin/test: No such file or directory
>/usr/bin/test: No such file or directory
>/usr/ubin/test: No such file or directory

The problem is that you do not HAVE the "test" program on your system.
The bug here is that the find program doesn't complain when it can't
exec the argument to "-exec".  It does, at least, return a nonzero
status from the attempt; that's why your added "!" made it always
return success.

>Is find using some other "test" than the one that is accessable from the shell?
>(ksh, by the way)

Well, the "test" command you tested is *built in* to the shell, and
therefore not accessable from anywhere else.  (Find can only exec
"real" programs, not shell built-in commands.)  You could modify
your command to run a shell:

$ find f -type f -links 1 -exec sh -c "test -r $0" {} \; -print

although that example relies on an undocumented feature of the
Bourne shell (That $0 is the first agrument when the -c option is
used).

The best solution would be to get a copy of the "test" program.
You might already have it under the name "/bin/[", in which case
you can just make a link.
-- 
					-=] Ford [=-

	.		.		(In Real Life: Mike Ditto)
.	    :	       ,		ford at kenobi.cts.com
This space under construction,		...!ucsd!elgar!ford
pardon our dust.			ditto at cbmvax.commodore.com