Follow-up Comment #6, bug #18554 (project findutils):
POSIX definitely only allows + to be special when it immediately follows {}.
I can see that because the text doesn't say immediately follows it could be
misinterpreted, but the requirement is clear from the specified form of the
primary:
Follow-up Comment #7, bug #18554 (project findutils):
Thanks for the (pretty much) official interpretation Geoff.
The findutils documentation would not include an example showing how to
accomplish this with sh -c though, because of the disastrous security
implications of passing untrusted data
Update of bug #18554 (project findutils):
Status:None = Invalid
___
Follow-up Comment #8:
I'm marking this feature request Invalid on the grounds that the requested
change would be
Update of bug #18554 (project findutils):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?18554
___
Follow-up Comment #9, bug #18554 (project findutils):
James, I believe the way I suggested using sh -c is perfectly safe. The
security problem you are thinking of is associated with uses where the {} is
part of the command, e.g.
find ... -exec sh -c 'ls -l {}' \;
which is not portable anyway.
Follow-up Comment #11, bug #18554 (project findutils):
I can't see any _security_ problem with that construct, either.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?18554
___
Follow-up Comment #12, bug #18554 (project findutils):
I agree that
find startpoint -tests ... -exec sh -c 'scp $@ remote:/dest' sh {} +
has no security problems, because sh is not parsing the arguments. The only
time you have a security problem when passing arbitrary filenames to sh is
when
Follow-up Comment #13, bug #18554 (project findutils):
Egmont, you raise an interesting point about the limit on the number of
arguments. There is nothing in POSIX about such a limit, but I don't think
there is anything that forbids it either.
The -exec sh -c 'utility ... $@ ...' sh {} +
Update of bug #18554 (project findutils):
Category:find = documentation
Status: Invalid = None
Open/Closed: Closed = Open
Follow-up Comment #15, bug #18554 (project findutils):
One other thing to throw in the mix:
POSIX has no requirements on -execdir. Therefore, I argue that it might make
sense to have -execdir be as friendly as possible, and allow the {} to appear
anywhere, rather than only immediately before
Follow-up Comment #3, bug #18554 (project findutils):
OK, I have now spent some time re-reading the standard at
http://www.opengroup.org/onlinepubs/009695399/utilities/find.html.
The last thing before the + must be {}. That {} will be replaced by an
aggregated set of pathnames. Hence
Update of bug #18554 (project findutils):
Assigned to:None = jay
___
Reply to this item at:
http://savannah.gnu.org/bugs/?18554
___
Follow-up Comment #4, bug #18554 (project findutils):
Sorry, the previous update was the victim of rich-text processing. That last
command should have been
printf funny\nscary\n | xargs -I X -L10 echo hello X world
(I originally used an underscopre but Savannah uses those to denote italics,
Follow-up Comment #5, bug #18554 (project findutils):
I'm just reading the standard you have linked, and I still can't see it
explicitely stating that {} must _immediately_ precede the + sign.
However, it says: An argument containing only the two characters {} shall
be replaced by the set of
URL:
http://savannah.gnu.org/bugs/?18554
Summary: feat req: -exec cmd {} more args +
Project: findutils
Submitted by: egmont
Submitted on: Tuesday 12/19/2006 at 12:58
Category: find
Severity: 3 - Normal
15 matches
Mail list logo
