bugfindutils - Bugs: bug #17782, unwanted prefix "./"...

 
 

bug #17782: unwanted prefix "./" before arguments when using -execdir with find

Submitted by:  Andreas Metzler <ametzler>
Submitted on:  Sun 17 Sep 2006 10:51:44 AM UTC  
 
Category: findSeverity: 4 - Important
Item Group: Wrong resultStatus: Fixed
Privacy: PublicAssigned to: James Youngman <jay>
Originator Name: WANG YunfengOpen/Closed: Closed
Release: 4.2.28Fixed Release: 4.2.29

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Wed 08 Nov 2006 07:12:16 AM UTC, comment #7:

This is fixed in CVS for both 4.2.x and 4.3.x.

James Youngman <jay>
Project AdministratorIn charge of this item.
Wed 08 Nov 2006 07:11:51 AM UTC, comment #6:

This problem is fixed in the CVS code for findutils.
To resolve your problem, you could either wait for the
next official release of findutils, or check out a copy
of the code from the CVS repository for findutils.

James Youngman <jay>
Project AdministratorIn charge of this item.
Thu 19 Oct 2006 06:03:17 PM UTC, comment #5:

Well, if that is not the outcome you expected, I should fix the documentation. I won't be making the change you suggest as that would break the secure handling of files with names like "-i".

James Youngman <jay>
Project AdministratorIn charge of this item.
Thu 19 Oct 2006 05:26:51 PM UTC, comment #4:

WANG Yunfeng in http://bugs.debian.org/385896

> Follow-up Comment #1:
>
> Prefixing the expansion of {} with ./ is a security feature. I'm not
> planning to remove it.
>
> However, as Andreas points out the actual bug here is that arguments
> containing {} are prefixed with ./ at the start of the argument, even if the
> {} is not at the start of the argument. Example:
>
>
> $ find baz -execdir echo 'foo {}' \;
> ./foo baz

Here we need a little more consideration. Thinking about this situation:

Under current directory exists some file whose name looks like `bashrc',
and I want to rename it to `.bashrc', so I would probably run:

$ find . -name "[^.]*rc" -execdir mv {} .{} \;

According to patch file sv-bug-17782.patch, this will result in a command
like `mv ./bashrc ../bashrc', which is definitely not expected.

As a compromise, I suggest to provide an option, say `-suppress_prefix',
to disable this feature for those who really don't need it with -execdir,
while enable it by default for the general purpose invokation.

Andreas Metzler <ametzler>
Mon 16 Oct 2006 09:47:44 AM UTC, comment #3:

The attached patch (against 4.2.x CVS) should fix the problem.

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 15 Oct 2006 01:42:48 PM UTC, comment #2:

This bug affects all versions of versions of findutils which support -execdir:

findutils-4.2.12
findutils-4.2.13
findutils-4.2.14
findutils-4.2.15
findutils-4.2.16
findutils-4.2.17
findutils-4.2.18
findutils-4.2.19
findutils-4.2.20
findutils-4.2.21
findutils-4.2.22
findutils-4.2.23
findutils-4.2.24
findutils-4.2.25
findutils-4.2.26
findutils-4.2.27
findutils-4.2.28
findutils-4.3.0
findutils-4.3.1

Versions of findutils prior to 4.2.12 don't support -execdir and are thus not affected.

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 15 Oct 2006 12:11:12 PM UTC, comment #1:

Prefixing the expansion of {} with ./ is a security feature. I'm not planning to remove it.

However, as Andreas points out the actual bug here is that arguments containing {} are prefixed with ./ at the start of the argument, even if the {} is not at the start of the argument. Example:

$ find baz -execdir echo 'foo {}' \;
./foo baz

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 17 Sep 2006 10:51:44 AM UTC, original submission:

This http://bugs.debian.org/385896 reported by WANG Yunfeng.

Short version
Bug:
ametzler@argenau:/tmp/testingfind$ find -type f -execdir echo sh -c 'file -b {} | true' \;
sh -c ./file -b d | true
Expected output
sh -c file -b ./d | true

Complete original bugreport follows:
---------------------------------------
When action "-execdir" was used with find, a string "./" was prepended
to any argument containing replace pattern "{}", leading to this error:

$ find -type f ! -name "*.gz" -execdir sh -c \

> 'file -b {} | grep -q "gzip compressed data" && mv {} {}.gz' \;

sh: ./file: No such file or directory

I've gone through codes related with this prefixing behavior in the
source code of findutils, and found these relevant lines:

line 509 in find/pred.c :
const char *prefix = (state.rel_pathname[0] == '/') ? NULL : "./";
lines 278+ in lib/buildcmd.c :
if (prefix)
{
strcpy (state->argbuf + state->cmd_argv_chars, prefix);
state->cmd_argv_chars += pfxlen;
}
...

In most cases such design was not a bad idea since {} was generally
placed alone, sometimes even quite good for dealing with unusual file
names like "-l". But if we want to do some complex operations as shown
above, this will turn to be a mess.

Possible resolution could be discarding this feature since those who
need prefix "./" can specify it explicitly at the beginning of argument;
or at least a switch to turn off this behavior should be provided.

Another possible bug concerning "-execdir" shown below:

$ pwd
/tmp
$ find / -maxdepth 1 -wholename / -execdir pwd \;
/tmp
$ find / -maxdepth 1 -wholename /boot -execdir pwd \;
/

Among these two find invocations, the latter conforms to the description
in find's manpage while the former does not. This inconsistency seems to
occur only when the matching filename was "/". I'm not sure if this is
another special handling or not.

ps: action "-okdir" works basically the same way as "-execdir".
-------------------------------

Andreas Metzler <ametzler>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #10981:  sv-bug-17782.patch added by jay (2KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jay (Updated the item)
  • -unavailable- added by ametzler (original bug submitter)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 26 Nov 2006 06:55:21 PM UTCjayItem GroupNone=>Wrong result
      Open/ClosedOpen=>Closed
      Fixed ReleaseNone=>4.2.29
    Wed 08 Nov 2006 07:13:46 AM UTCjayStatusNone=>Fixed
    Mon 16 Oct 2006 09:47:44 AM UTCjayAttached File-=>Added sv-bug-17782.patch, #10981
    Sun 15 Oct 2006 12:11:12 PM UTCjaySeverity3 - Normal=>4 - Important
      Assigned toNone=>jay
    Sun 17 Sep 2006 10:51:44 AM UTCametzlerCarbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup1