Re: Find -mtime weird behaviour
From: Richard L. Hamilton (Richard.L.Hamilton_at_mindwarp.smart.net)
Date: 03/30/05
- Next message: hal_at_nospam.com: "Disksuite for 2.6 download from somewhere?"
- Previous message: Oscar del Rio: "Re: Forcing Boot to CD\DVD on SPARC"
- In reply to: Michael Tosch: "Re: Find -mtime weird behaviour"
- Next in thread: Casper H.S. Dik: "Re: Find -mtime weird behaviour"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 30 Mar 2005 21:55:49 -0000
In article <d2f4a5$lb4$1@aken.eed.ericsson.se>,
Michael Tosch <eedmit@NO.eed.SPAM.ericsson.PLS.se> writes:
> Darren Dunham wrote:
>> Michael Tosch <eedmit@no.eed.spam.ericsson.pls.se> wrote:
>>
>>
>>>Nope, besides that it should be
>>>find . -type f -mtime +20 -print | xargs rm -f
>>
>>
>>>only this one is safe:
>>
>>
>>>find . -type f -mtime +20 -exec rm -f {} \;
>>
>>
>> Safe and slow.
>>
>> find . -type f -mtime +20 -exec rm -f {} +
>>
>> Safe and faster.
>>
>
> It really works!
> How did you discover that feature?
>
> man find sais
>
> -exec command
> True if the executed command returns a zero value as
> exit status. The end of command must be punctuated by
> an escaped semicolon. A command argument {} is
> replaced by the current path name.
>
>From the Solaris 9 version of find(1) man page:
-exec command
True if the executed command returns a zero value as
exit status. The end of command must be punctuated by
an escaped semicolon (;). A command argument {} is
replaced by the current path name. If the last argu-
ment to -exec is {} and you specify + rather than the
semicolon (;), the command will be invoked fewer
times, with {} replaced by groups of pathnames.
Turns out that on Solaris, the feature has been there just about
forever (at least since 2.x or x, for very low values of x) but
has only recently been documented.
And you can't even complain it's non-standard! The current incarnation
of the Single Unix Specification reflects it:
http://www.opengroup.org/onlinepubs/009695399/utilities/find.html#tag_04_55_05
-exec utility_name [argument ...] ;
-exec utility_name [argument ...] {} +
The end of the primary expression shall be punctuated by a
semicolon or by a plus sign. Only a plus sign that follows an
argument containing the two characters "{}" shall punctuate the
end of the primary expression. Other uses of the plus sign shall
not be treated as special.
If the primary expression is punctuated by a semicolon, the
utility utility_name shall be invoked once for each pathname and
the primary shall evaluate as true if the utility returns a zero
value as exit status. A utility_name or argument containing only
the two characters "{}" shall be replaced by the current pathname.
If the primary expression is punctuated by a plus sign, the
primary shall always evaluate as true, and the pathnames for which
the primary is evaluated shall be aggregated into sets. The
utility utility_name shall be invoked once for each set of
aggregated pathnames. Each invocation shall begin after the last
pathname in the set is aggregated, and shall be completed before
the find utility exits and before the first pathname in the next
set (if any) is aggregated for this primary, but it is otherwise
unspecified whether the invocation occurs before, during, or after
the evaluations of other primaries. If any invocation returns a
non-zero value as exit status, the find utility shall return a
non-zero exit status. An argument containing only the two
characters "{}" shall be replaced by the set of aggregated
pathnames, with each pathname passed as a separate argument to the
invoked utility in the same order that it was aggregated. The
size of any set of two or more pathnames shall be limited such
that execution of the utility does not cause the system's
{ARG_MAX} limit to be exceeded. If more than one argument
containing only the two characters "{}" is present, the behavior
is unspecified.
If a utility_name or argument string contains the two characters
"{}", but not just the two characters "{}", it is
implementation-defined whether find replaces those two characters
or uses the string without change. The current directory for the
invocation of utility_name shall be the same as the current
directory when the find utility was started. If the utility_name
names any of the special built-in utilities (see Special Built-In
Utilities), the results are undefined.
So it looks to me like Sun probably originated this useful feature
(similar to GNU find -print0 together with GNU xargs -0; that is, safe for
files with strange characters in their names, but as one process) _and_
managed to get it adopted in the current revision of (by definition) _the_
Unix standard.
That's a reasonable example of playing well with others, IMO; source or no
source.
-- mailto:rlhamil@smart.net http://www.smart.net/~rlhamil Lasik/PRK theme music: "In the Hall of the Mountain King", from "Peer Gynt"
- Next message: hal_at_nospam.com: "Disksuite for 2.6 download from somewhere?"
- Previous message: Oscar del Rio: "Re: Forcing Boot to CD\DVD on SPARC"
- In reply to: Michael Tosch: "Re: Find -mtime weird behaviour"
- Next in thread: Casper H.S. Dik: "Re: Find -mtime weird behaviour"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
