Bug in find(1) in 4.2BSD?

[Steve Wall]

I've run into the following bug in find(1) in 4.2BSD. I know that there
was some talk on the USENET about 4 months ago regarding find, but
I'm not sure if this is what was being discussed. I'm pretty sure that
I'm using the command correctly, at least as far as the manual page goes.

The problem occurs when the -exec field is used with "ls -l" (I don't know
if it occurs with other programs that are execed). Here is a script of the 
problem:

===============================================
Script started on Thu Oct  4 07:47:30 1984
arpa % pwd
/ra/csr/wall/test

arpa % ls
1/          2/          in_test     typescript

arpa % ls 1
file_find

arpa % ls 2
file_find

arpa % find . -name file_find -exec ls -l {}\;
total 2
drwxr-xr-x  2 wall          512 Oct  4 06:46 1
drwxr-xr-x  2 wall          512 Oct  4 06:46 2
-rw-r--r--  1 wall            0 Oct  4 06:46 in_test
-rw-r--r--  1 wall            0 Oct  4 07:47 typescript
total 2
drwxr-xr-x  2 wall          512 Oct  4 06:46 1
drwxr-xr-x  2 wall          512 Oct  4 06:46 2
-rw-r--r--  1 wall            0 Oct  4 06:46 in_test
-rw-r--r--  1 wall            0 Oct  4 07:47 typescript

arpa % exit
script done on Thu Oct  4 07:48:26 1984

===============================================
The problem seems to be that "find" finds the two matches, but instead
of using the paths of the matches for the "ls -l", it uses the current
directory. This doesn't seem right. Is this a problem with "ls" or is
it a problem with "find"? I've also tried:

	find . -name file_find -print | ls -l

but that produces the same output. Any help is appreciated.

Steve Wall
wall at ucbarpa	(ARPANET)
..!ucbvax!wall	(UUCP)