Debian Bug report logs -
#385896
findutils: unwanted prefix "./" before arguments when using -execdir with find
Toggle useless messages
Report forwarded to debian-bugs-dist@lists.debian.org, Andreas Metzler <ametzler@debian.org>:
Bug#385896; Package findutils.
(full text, mbox, link).
Acknowledgement sent to WANG Yunfeng <uhuruh@gmail.com>:
New Bug report received and forwarded. Copy sent to Andreas Metzler <ametzler@debian.org>.
(full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
Package: findutils
Version: 4.2.28-1
Severity: normal
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".
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-1-k7
Locale: LANG=zh_CN.GBK, LC_CTYPE=zh_CN.GBK (charmap=GBK)
Versions of packages findutils depends on:
ii libc6 2.3.6-15 GNU C Library: Shared libraries
findutils recommends no packages.
-- no debconf information
--
Message sent on to WANG Yunfeng <uhuruh@gmail.com>:
Bug#385896.
(full text, mbox, link).
Message #10 received at 385896-submitter@bugs.debian.org (full text, mbox, reply):
URL:
<http://savannah.gnu.org/bugs/?17782>
Summary: unwanted prefix "./" before arguments when using
-execdir with find
Project: findutils
Submitted by: ametzler
Submitted on: Sonntag 17.09.2006 um 12:51
Category: find
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Originator Name: WANG Yunfeng
Originator Email:
Open/Closed: Open
Release: 4.2.28
Fixed Release: None
_______________________________________________________
Details:
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".
-------------------------------
_______________________________________________________
Carbon-Copy List:
CC Address | Comment
------------------------------------+-----------------------------
Available only the item webpage | original bug submitter
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?17782>
_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/
Message sent on to WANG Yunfeng <uhuruh@gmail.com>:
Bug#385896.
(full text, mbox, link).
Message #13 received at 385896-submitter@bugs.debian.org (full text, mbox, reply):
Update of bug #17782 (project findutils):
Severity: 3 - Normal => 4 - Important
Assigned to: None => jay
_______________________________________________________
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
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?17782>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Message sent on to WANG Yunfeng <uhuruh@gmail.com>:
Bug#385896.
(full text, mbox, link).
Message #16 received at 385896-submitter@bugs.debian.org (full text, mbox, reply):
Follow-up Comment #2, bug #17782 (project findutils):
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.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?17782>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Message sent on to WANG Yunfeng <uhuruh@gmail.com>:
Bug#385896.
(full text, mbox, link).
Message #19 received at 385896-submitter@bugs.debian.org (full text, mbox, reply):
Follow-up Comment #3, bug #17782 (project findutils):
The attached patch (against 4.2.x CVS) should fix the problem.
_______________________________________________________
Additional Item Attachment:
File name: sv-bug-17782.patch Size:1 KB
<http://savannah.gnu.org/bugs/download.php?file_id=10981>
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?17782>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Metzler <ametzler@debian.org>:
Bug#385896; Package findutils.
(full text, mbox, link).
Acknowledgement sent to WANG Yunfeng <uhuruh@gmail.com>:
Extra info received and forwarded to list. Copy sent to Andreas Metzler <ametzler@debian.org>.
(full text, mbox, link).
Message #24 received at 385896@bugs.debian.org (full text, mbox, reply):
On Sun, Oct 15, 2006 at 12:11:14PM +0000, James Youngman wrote:
>
> Update of bug #17782 (project findutils):
>
> Severity: 3 - Normal => 4 - Important
> Assigned to: None => jay
>
> _______________________________________________________
>
> 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.
>
>
> _______________________________________________________
>
> Reply to this item at:
>
> <http://savannah.gnu.org/bugs/?17782>
>
> _______________________________________________
> Message sent via/by Savannah
> http://savannah.gnu.org/
>
Message sent on to WANG Yunfeng <uhuruh@gmail.com>:
Bug#385896.
(full text, mbox, link).
Message #27 received at 385896-submitter@bugs.debian.org (full text, mbox, reply):
Follow-up Comment #4, bug #17782 (project findutils):
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.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?17782>
_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/
Message sent on to WANG Yunfeng <uhuruh@gmail.com>:
Bug#385896.
(full text, mbox, link).
Message #30 received at 385896-submitter@bugs.debian.org (full text, mbox, reply):
Follow-up Comment #5, bug #17782 (project findutils):
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".
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?17782>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Message sent on to WANG Yunfeng <uhuruh@gmail.com>:
Bug#385896.
(full text, mbox, link).
Message #33 received at 385896-submitter@bugs.debian.org (full text, mbox, reply):
Follow-up Comment #6, bug #17782 (project findutils):
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.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?17782>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Message sent on to WANG Yunfeng <uhuruh@gmail.com>:
Bug#385896.
(full text, mbox, link).
Message #36 received at 385896-submitter@bugs.debian.org (full text, mbox, reply):
Follow-up Comment #7, bug #17782 (project findutils):
This is fixed in CVS for both 4.2.x and 4.3.x.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?17782>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Message sent on to WANG Yunfeng <uhuruh@gmail.com>:
Bug#385896.
(full text, mbox, link).
Message #39 received at 385896-submitter@bugs.debian.org (full text, mbox, reply):
Update of bug #17782 (project findutils):
Status: None => Fixed
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?17782>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Message sent on to WANG Yunfeng <uhuruh@gmail.com>:
Bug#385896.
(full text, mbox, link).
Message #42 received at 385896-submitter@bugs.debian.org (full text, mbox, reply):
Update of bug #17782 (project findutils):
Item Group: None => Wrong result
Open/Closed: Open => Closed
Fixed Release: None => 4.2.29
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?17782>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Reply sent to Andreas Metzler <ametzler@debian.org>:
You have taken responsibility.
(full text, mbox, link).
Notification sent to WANG Yunfeng <uhuruh@gmail.com>:
Bug acknowledged by developer.
(full text, mbox, link).
Message #47 received at 385896-close@bugs.debian.org (full text, mbox, reply):
Source: findutils
Source-Version: 4.2.28-2
We believe that the bug you reported is fixed in the latest version of
findutils, which is due to be installed in the Debian FTP archive:
findutils_4.2.28-2.diff.gz
to pool/main/f/findutils/findutils_4.2.28-2.diff.gz
findutils_4.2.28-2.dsc
to pool/main/f/findutils/findutils_4.2.28-2.dsc
findutils_4.2.28-2_i386.deb
to pool/main/f/findutils/findutils_4.2.28-2_i386.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 385896@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Andreas Metzler <ametzler@debian.org> (supplier of updated findutils package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Sun, 25 Feb 2007 10:44:55 +0100
Source: findutils
Binary: findutils
Architecture: source i386
Version: 4.2.28-2
Distribution: unstable
Urgency: low
Maintainer: Andreas Metzler <ametzler@debian.org>
Changed-By: Andreas Metzler <ametzler@debian.org>
Description:
findutils - utilities for finding files--find, xargs, and locate
Closes: 385896
Changes:
findutils (4.2.28-2) unstable; urgency=low
.
* Pulled from 4.2.29
- Fix breakage with slightly more complicated commands and -exedir.
(Closes: #385896)
Files:
a5ea8e714c48dc156359be4150de9220 663 utils required findutils_4.2.28-2.dsc
14c0e5560ef089fe7aa3eff1dfd0c0cf 15368 utils required findutils_4.2.28-2.diff.gz
e6cbbafe890f4b088ce46945f1155d29 350668 utils required findutils_4.2.28-2_i386.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFF4Vy9HTOcZYuNdmMRAkahAJ0eWXTLv6r1aYwGM28IG7UsMNSsKQCdFXyU
43j40aikjzLEvKO+/9l7yGI=
=LuK5
-----END PGP SIGNATURE-----
Bug reassigned from package `findutils' to `findutils'.
Request was from Andreas Metzler <ametzler@debian.org>
to control@bugs.debian.org.
(Sun, 15 Apr 2007 17:24:02 GMT) (full text, mbox, link).
Bug marked as found in version 4.2.28-1.
Request was from Andreas Metzler <ametzler@debian.org>
to control@bugs.debian.org.
(Sun, 15 Apr 2007 17:24:03 GMT) (full text, mbox, link).
Bug marked as fixed in version 4.2.28-2, send any further explanations to WANG Yunfeng <uhuruh@gmail.com>
Request was from Andreas Metzler <ametzler@debian.org>
to control@bugs.debian.org.
(Sun, 15 Apr 2007 17:24:04 GMT) (full text, mbox, link).
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Fri, 05 Oct 2007 07:30:19 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debian bug tracking system administrator <owner@bugs.debian.org>.
Last modified:
Sat Dec 23 16:19:13 2023;
Machine Name:
buxtehude
Debian Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.