wall@ucbvax.ARPA (Steve Wall) (10/04/84)
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@ucbarpa (ARPANET)
..!ucbvax!wall (UUCP)alan@drivax.UUCP (Alan Fargusson) (10/05/84)
<<<< gulp >>>>
This is not a bug. The problem is that csh eats {}. try this:
find . -name something -exec ls -l "{}" \;matt@ucla-cs.UUCP (10/06/84)
#endif bug >From: wall@ucbvax.ARPA (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. > >... >arpa % find . -name file_find -exec ls -l {}\; >... The find command is being issued incorrectly. Since you are using Csh, the sequence {}\; is being ``expanded'' to `;', and you are really doing an `ls -l' each time a file is found (prove this to yourself with `echo {}\;'). Try: find . -name file_find -exec ls -l "{}" \; which should work correctly. - Matt ------- UUCP: {ucbvax,ihnp4}!ucla-cs!locus.matt ARPA: matt@ucla-locus
jerry@oliveb.UUCP (Jerry Aguirre) (10/09/84)
No the csh does not eat {}. Actually I was supprised that it didn't as
{a,b}c does have special meaning to the csh. Apparently the shell
recognizes that {} cannot be expanded and so leaves it alone. The real
problem with the posted line is that there is no space between the {}
and the \;. That is:
find . -name something -exec ls -l {}\;
won't work but
find . -name something -exec ls -l {} \;
will. Note space ^
Remember that the \; is the terminating argument for the string of
arguments beginning with -exec. To be recognized it must be a separate
argument.
Jerry Aguirre
{hplabs|fortune|idi|ihnp4|ios|tolerant|allegra|tymix}!oliveb!jerrysid@linus.UUCP (Sid Stuart) (02/17/85)
Date: Feb 16 1985 From: Sid Stuart at linus!sid Subject: Fix for find dumping core. Index: find.c 4.2 Description: Find dumped core on me. The problem occurs when the code uses a table of pointers to functions. Most of the functions want a pointer to a structure passed to them as a parameter. Three of them don't, print, cpio, and newer. When the pointer to one of these is used, the pointer to the structure is passed, but they are not set up to handle it. The fix is pretty obvious, have them accept the pointer, even though they don't use it. Repeat by: Well, it dumped core on me when I said, find / -user news -print | more but I think the malfunction could be random. Fix: This is from a "diff find.old find.fixed" 287c301,308 < print() --- > print(trash) /* The trash variable is not used. It is needed because > the function is called by pointer from a table. > When functions are called from the table, they > passed a pointer to an anode structure. > If print does not accept this argument, find will sometimes > dump core. > */ > register struct anode *trash; 371c401,402 < cpio() --- > cpio(trash) /* The trash variable is not used. See definition of print. */ > register struct anode *trash; 428c459,460 < newer() --- > newer(trash) /* The trash variable is not used. See definition of print. */ > register struct anode *trash; /* End of bug report */