From nobody  Fri Aug 29 17:03:51 1997
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA07911;
          Fri, 29 Aug 1997 17:03:51 -0700 (PDT)
Message-Id: <199708300003.RAA07911@hub.freebsd.org>
Date: Fri, 29 Aug 1997 17:03:51 -0700 (PDT)
From: imp@village.org
To: freebsd-gnats-submit@freebsd.org
Subject: find -exedir doesn't chdir for first entry
X-Send-Pr-Version: www-1.0

>Number:         4420
>Category:       bin
>Synopsis:       [patch] find(1) -exedir doesn't chdir for first entry
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    imp
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Aug 29 17:10:00 PDT 1997
>Closed-Date:    Thu Mar 13 22:39:02 MDT 2014
>Last-Modified:  Thu Mar 13 22:39:02 MDT 2014
>Originator:     Warner Losh
>Release:        3.0-current
>Organization:
The Village Networking Association
>Environment:
FreeBSD harmony.village.org 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Fri Aug 29 00:04:41 MDT 1997     imp@harmony.village.org:/home/imp/FreeBSD/src/sys/compile/GENERIC  i386

>Description:
% cd /usr
% find /tmp -type d -execdir pwd \;
/usr
/tmp
/tmp

For reasons unknown the first entry is down with pwd == /usr rather than
/tmp.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:

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
 

From: Bruce Evans <bde@zeta.org.au>
To: dzerkel@columbus.rr.com, freebsd-bugs@FreeBSD.ORG
Cc: freebsd-gnats-submit@FreeBSD.ORG, imp@village.org
Subject: Re: bin/4420: find -exedir doesn't chdir for first entry
Date: Thu, 12 Aug 1999 17:04:12 +1000

 > 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.
 
 The XXX comment in f_exedir() says that paths with trailing slashes are
 mishandled if they actually occur.
 
 Bruce
 

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: Thu, 12 Aug 1999 21:54:00 -0400

 > From: Bruce Evans <bde@zeta.org.au>
 >
 > The XXX comment in f_exedir() says that paths with trailing slashes are
 > mishandled if they actually occur.
 
 Ahh, yes.  Didn't think about it from that end of the path.  Well, my
 patch
 does nothing to repair or further break that mishandling.  I suppose one
 could set {} to '.'.  It would be technically correct, but the
 ramifications
 would be difficult to guess.
 
 -- Danny J. Zerkel
 dzerkel@columbus.rr.com
 
Responsible-Changed-From-To: freebsd-bugs->roberto 
Responsible-Changed-By: nrahlstr 
Responsible-Changed-When: Mon Jun 5 21:52:35 PDT 2000 
Responsible-Changed-Why:  
Ollivier has kindly agreed to look over find(1) related PR's. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=4420 

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: Sun, 15 Jul 2001 23:29:29 -0400

 Problem still occurs, anyone want to go for the patch given?
 
 Danny
 ------------------
 dzerkel@columbus.rr.com

From: Warner Losh <imp@harmony.village.org>
To: "Danny J. Zerkel" <dzerkel@columbus.rr.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/4420: find -exedir doesn't chdir for first entry 
Date: Sun, 15 Jul 2001 21:41:34 -0600

 In message <01071523292901.23520@zoomer> "Danny J. Zerkel" writes:
 : Problem still occurs, anyone want to go for the patch given?
 
 If the patch works, I'll commit it.  If you can, please assign it to
 me. 
 
 Warner

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: Mon, 16 Jul 2001 23:06:19 -0400

 I have updated the patch to do memory allocation outside of the fork and
 to match up to current find sources.  The manual page specifically states
 that {} with -execdir is not qualified, so having be the empty string in paths
 that end in / is probably not a problem, per se.
 
 --- usr.bin/find/function.c.orig        Mon Jul 16 21:57:03 2001
 +++ usr.bin/find/function.c     Mon Jul 16 22:58:38 2001
 @@ -444,12 +444,25 @@
         pid_t pid;
         int status;
         char *file;
 +       char *dir;
 +
 +       dir = NULL;
  
         /* XXX - if file/dir ends in '/' this will not work -- can it? */
         if ((plan->flags & F_EXECDIR) && \
 -           (file = strrchr(entry->fts_path, '/')))
 -               file++;
 -       else
 +           (file = strrchr(entry->fts_path, '/'))) {
 +               if (entry->fts_accpath == entry->fts_path) {
 +                       if (file == entry->fts_path) {
 +                               dir = strdup("/");
 +                               file = ".";
 +                       } else {
 +                               *file = 0;
 +                               dir = strdup(entry->fts_path);
 +                               *file++ = '/';
 +                       }
 +               } else
 +                       file++;
 +       } else
                 file = entry->fts_path;
  
         for (cnt = 0; plan->e_argv[cnt]; ++cnt)
 @@ -474,11 +487,18 @@
                         warn("chdir");
                         _exit(1);
                 }
 +               if (dir != NULL && chdir(dir)) {
 +                       warn("chdir");
 +                       _exit(1);
 +               }
                 execvp(plan->e_argv[0], plan->e_argv);
                 warn("%s", plan->e_argv[0]);
                 _exit(1);
         }
         pid = waitpid(pid, &status, 0);
 +       if (dir != NULL) {
 +               free(dir);
 +       }
         return (pid != -1 && WIFEXITED(status) && !WEXITSTATUS(status));
  }
 
 
 I would assign it if I could...  I would patch it myself if I could, also...
 ------------------
 dzerkel@columbus.rr.com
Responsible-Changed-From-To: roberto->jmallett 
Responsible-Changed-By: jmallett 
Responsible-Changed-When: Thu Aug 22 21:32:22 PDT 2002 
Responsible-Changed-Why:  
I've been asked by one of the followup folks to look after this 
orphan, and I seem to recall asking roberto a while ago if I could 
assign it to myself, but forgot to make the change. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=4420 
Responsible-Changed-From-To: jmallett->imp 
Responsible-Changed-By: jmallett 
Responsible-Changed-When: Wed Jun 16 01:52:52 HST 2004 
Responsible-Changed-Why:  
Get this patch off my hands, imp said in the trail he'd look over it, 
and now, some years later, he can do it, I'm not 100% sure I understand 
all the implications as well as Warner ;) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=4420 
State-Changed-From-To: open->closed 
State-Changed-By: imp 
State-Changed-When: Thu Mar 13 22:38:29 MDT 2014 
State-Changed-Why:  
OBE 


http://www.freebsd.org/cgi/query-pr.cgi?pr=4420 
>Unformatted:
