compressdir bug?
Derek E. Terveer
det at hawkmoon.MN.ORG
Mon Sep 5 08:08:40 AEST 1988
In article <442 at gt-ford.gtisqr.UUCP>, stu at gtisqr.UUCP (Stu Donaldson) writes:
> In article <303 at hawkmoon.MN.ORG>, root at hawkmoon.MN.ORG (Admin) writes:
>
> > There is a missing `!' just before the -exec in the find.
>
> find $@ -type f -links 1 -exec test -r {} -a -s {} \; \
> -exec expr '(' {} : '.*\.Z' ')' '=' 0 \; \
> -exec compress $OPTIONS {} \; >/dev/null
>
> My copy of compressdir does not have the '!' and works
> just as I expect it to. The test after the first exec
> is testing to see if the file is readable, and has a
> size greater than 0. If you put a '!' in, then things
> shouldn't work, because it will only try and compress
> files that either aren't readable, or have a size of 0.
>
> Did I misunderstand something?
I don't think so -- your analysis of the command is correct, however perhaps
this is a case where i may be forced to stick my foot in my mouth and wiggle my
toes vigoursly... (:-( I assumed that because it didn't seem to work on MY
system (uPort V/386 3.0-L2.2) that it was a bug.
I any event this is why i decided to insert the "!" (before the first exec) in
my copy of compressdir:
$ cd /tmp
$ touch f #create a file
$ chmod 777 f #make it readable
$ ls -l /tmp/f #show it as readable, n'est pas?
-rwxrwxrwx 1 det sys 39 Sep 2 01:05 /tmp/f
$ type test #where am i picking up test?
test is a shell builtin
$ 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
$ 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!
$ find f -type f -links 1 ! -exec test -r {} \; -print #try the reverse - yes
f
$ echo exit 0 >/tmp/retcode #create a program to return an exit code
$ chmod 777 /tmp/retcode #make it executable
$ find f -type f -links 1 -exec /tmp/retcode \; -print #this works as expected
f
$ echo exit 1 >/tmp/retcode #reverse sense of exit code
$ find f -type f -links 1 -exec /tmp/retcode \; -print #so does this!
$
So what is going on here? Now, did I misunderstand something????
Is find using some other "test" than the one that is accessable from the shell?
(ksh, by the way)
derek
--
Derek Terveer det at hawkmoon.MN.ORG
w(612)681-6986 h(612)688-0667
"A proper king is crowned" -- Thomas B. Costain
More information about the Comp.bugs.sys5
mailing list