From owner-freebsd-bugs  Wed Aug 11 20:43:22 1999
Delivered-To: freebsd-bugs@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP id 1E1F214CF3
	for <freebsd-bugs@FreeBSD.org>; Wed, 11 Aug 1999 20:43:19 -0700 (PDT)
	(envelope-from gnats@FreeBSD.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id UAA31924;
	Wed, 11 Aug 1999 20:40:03 -0700 (PDT)
	(envelope-from gnats@FreeBSD.org)
Date: Wed, 11 Aug 1999 20:40:03 -0700 (PDT)
Message-Id: <199908120340.UAA31924@freefall.freebsd.org>
To: freebsd-bugs@FreeBSD.org
Cc: 
From: "Danny J. Zerkel" <dzerkel@columbus.rr.com>
Subject: Re: bin/4420: find -exedir doesn't chdir for first entry
Reply-To: "Danny J. Zerkel" <dzerkel@columbus.rr.com>
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

The following reply was made to PR bin/4420; it has been noted by GNATS.

From: "Danny J. Zerkel" <dzerkel@columbus.rr.com>
To: freebsd-gnats-submit@freebsd.org, imp@village.org
Cc:  
Subject: Re: bin/4420: find -exedir doesn't chdir for first entry
Date: Wed, 11 Aug 1999 23:36:37 -0400

 Warner,
 
 Find uses the fts functions, and the -execdir command is relying on the
 normal chdir
 functionality to leave the calling function in the right directory just
 before the exec.
 (Of course, there are a few scenarios in which fts doesn't use chdir,
 but we will ignore
 that since it would break -execdir completely, if they occured.)  -exec,
 in fact, has to
 force the directory back to the original directory in the child.  It
 turns out that if
 you match on directories, the origin directory of the search doesn't
 cause a chdir.  So,
 find is not where it expects to be.  So the following patch adds code to
 go do the explicit
 chdir in those cases.
 
 The question that remains is where should this be and what should the
 current directory be
 when you -execdir in that starting directory.  Well, a simple test shows
 a little more:
 
 $ find /tmp -type d -execdir echo {} \;
 tmp
 .X11-unix
 $
 
 This would seem to indicate that the resulting "hit" during execdir is
 defined as pwd + {}.
 So, I have coded this patch to remove the last directory from the path. 
 Thus, with my patch:
 
 $ find /tmp -type d -execdir pwd \; -execdir echo {} \;
 /
 tmp
 /tmp
 .X11-unix
 $
 
 Oddly enough, a find of / yeilds a pwd of / and an empty {}.  One can
 only wonder.
 
 --- /usr/src/usr.bin/find/function.c.orig       Tue Dec 15 23:50:46 1998
 +++ function.c  Wed Aug 11 23:22:18 1999
 @@ -419,6 +419,20 @@
                 err(1, "fork");
                 /* NOTREACHED */
         case 0:
 +               if (entry->fts_accpath == entry->fts_path &&
 +                 file != entry->fts_path) {
 +                       char *dir = strdup(entry->fts_path);
 +                       file = strrchr(dir, '/');
 +                       *file = 0;
 +                       if (*dir == 0) {
 +                               dir[0] = '/';
 +                               dir[1] = 0;
 +                       }
 +                       if (chdir(dir)) {
 +                               warn("chdir");
 +                               _exit(1);
 +                       }
 +               }
                 execvp(plan->e_argv[0], plan->e_argv);
                 warn("%s", plan->e_argv[0]);
                 _exit(1);
 
 
 -- Danny J. Zerkel
 dzerkel@columbus.rr.com
 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message