mirror of
https://gitlab.com/dwt1/dotfiles.git
synced 2026-04-14 04:38:29 +10:00
2562 lines
99 KiB
HTML
2562 lines
99 KiB
HTML
<?xml version="1.0" encoding="utf-8"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
||
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
|
||
<head>
|
||
<!-- 2021-12-23 Thu 19:44 -->
|
||
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
|
||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||
<title>find</title>
|
||
<meta name="author" content="dt" />
|
||
<meta name="description" content="Org-Man pages - find
|
||
Header
|
||
Footer" />
|
||
<meta name="generator" content="Org Mode" />
|
||
<style>
|
||
#content { max-width: 60em; margin: auto; }
|
||
.title { text-align: center;
|
||
margin-bottom: .2em; }
|
||
.subtitle { text-align: center;
|
||
font-size: medium;
|
||
font-weight: bold;
|
||
margin-top:0; }
|
||
.todo { font-family: monospace; color: red; }
|
||
.done { font-family: monospace; color: green; }
|
||
.priority { font-family: monospace; color: orange; }
|
||
.tag { background-color: #eee; font-family: monospace;
|
||
padding: 2px; font-size: 80%; font-weight: normal; }
|
||
.timestamp { color: #bebebe; }
|
||
.timestamp-kwd { color: #5f9ea0; }
|
||
.org-right { margin-left: auto; margin-right: 0px; text-align: right; }
|
||
.org-left { margin-left: 0px; margin-right: auto; text-align: left; }
|
||
.org-center { margin-left: auto; margin-right: auto; text-align: center; }
|
||
.underline { text-decoration: underline; }
|
||
#postamble p, #preamble p { font-size: 90%; margin: .2em; }
|
||
p.verse { margin-left: 3%; }
|
||
pre {
|
||
border: 1px solid #e6e6e6;
|
||
border-radius: 3px;
|
||
background-color: #f2f2f2;
|
||
padding: 8pt;
|
||
font-family: monospace;
|
||
overflow: auto;
|
||
margin: 1.2em;
|
||
}
|
||
pre.src {
|
||
position: relative;
|
||
overflow: auto;
|
||
}
|
||
pre.src:before {
|
||
display: none;
|
||
position: absolute;
|
||
top: -8px;
|
||
right: 12px;
|
||
padding: 3px;
|
||
color: #555;
|
||
background-color: #f2f2f299;
|
||
}
|
||
pre.src:hover:before { display: inline; margin-top: 14px;}
|
||
/* Languages per Org manual */
|
||
pre.src-asymptote:before { content: 'Asymptote'; }
|
||
pre.src-awk:before { content: 'Awk'; }
|
||
pre.src-authinfo::before { content: 'Authinfo'; }
|
||
pre.src-C:before { content: 'C'; }
|
||
/* pre.src-C++ doesn't work in CSS */
|
||
pre.src-clojure:before { content: 'Clojure'; }
|
||
pre.src-css:before { content: 'CSS'; }
|
||
pre.src-D:before { content: 'D'; }
|
||
pre.src-ditaa:before { content: 'ditaa'; }
|
||
pre.src-dot:before { content: 'Graphviz'; }
|
||
pre.src-calc:before { content: 'Emacs Calc'; }
|
||
pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
|
||
pre.src-fortran:before { content: 'Fortran'; }
|
||
pre.src-gnuplot:before { content: 'gnuplot'; }
|
||
pre.src-haskell:before { content: 'Haskell'; }
|
||
pre.src-hledger:before { content: 'hledger'; }
|
||
pre.src-java:before { content: 'Java'; }
|
||
pre.src-js:before { content: 'Javascript'; }
|
||
pre.src-latex:before { content: 'LaTeX'; }
|
||
pre.src-ledger:before { content: 'Ledger'; }
|
||
pre.src-lisp:before { content: 'Lisp'; }
|
||
pre.src-lilypond:before { content: 'Lilypond'; }
|
||
pre.src-lua:before { content: 'Lua'; }
|
||
pre.src-matlab:before { content: 'MATLAB'; }
|
||
pre.src-mscgen:before { content: 'Mscgen'; }
|
||
pre.src-ocaml:before { content: 'Objective Caml'; }
|
||
pre.src-octave:before { content: 'Octave'; }
|
||
pre.src-org:before { content: 'Org mode'; }
|
||
pre.src-oz:before { content: 'OZ'; }
|
||
pre.src-plantuml:before { content: 'Plantuml'; }
|
||
pre.src-processing:before { content: 'Processing.js'; }
|
||
pre.src-python:before { content: 'Python'; }
|
||
pre.src-R:before { content: 'R'; }
|
||
pre.src-ruby:before { content: 'Ruby'; }
|
||
pre.src-sass:before { content: 'Sass'; }
|
||
pre.src-scheme:before { content: 'Scheme'; }
|
||
pre.src-screen:before { content: 'Gnu Screen'; }
|
||
pre.src-sed:before { content: 'Sed'; }
|
||
pre.src-sh:before { content: 'shell'; }
|
||
pre.src-sql:before { content: 'SQL'; }
|
||
pre.src-sqlite:before { content: 'SQLite'; }
|
||
/* additional languages in org.el's org-babel-load-languages alist */
|
||
pre.src-forth:before { content: 'Forth'; }
|
||
pre.src-io:before { content: 'IO'; }
|
||
pre.src-J:before { content: 'J'; }
|
||
pre.src-makefile:before { content: 'Makefile'; }
|
||
pre.src-maxima:before { content: 'Maxima'; }
|
||
pre.src-perl:before { content: 'Perl'; }
|
||
pre.src-picolisp:before { content: 'Pico Lisp'; }
|
||
pre.src-scala:before { content: 'Scala'; }
|
||
pre.src-shell:before { content: 'Shell Script'; }
|
||
pre.src-ebnf2ps:before { content: 'ebfn2ps'; }
|
||
/* additional language identifiers per "defun org-babel-execute"
|
||
in ob-*.el */
|
||
pre.src-cpp:before { content: 'C++'; }
|
||
pre.src-abc:before { content: 'ABC'; }
|
||
pre.src-coq:before { content: 'Coq'; }
|
||
pre.src-groovy:before { content: 'Groovy'; }
|
||
/* additional language identifiers from org-babel-shell-names in
|
||
ob-shell.el: ob-shell is the only babel language using a lambda to put
|
||
the execution function name together. */
|
||
pre.src-bash:before { content: 'bash'; }
|
||
pre.src-csh:before { content: 'csh'; }
|
||
pre.src-ash:before { content: 'ash'; }
|
||
pre.src-dash:before { content: 'dash'; }
|
||
pre.src-ksh:before { content: 'ksh'; }
|
||
pre.src-mksh:before { content: 'mksh'; }
|
||
pre.src-posh:before { content: 'posh'; }
|
||
/* Additional Emacs modes also supported by the LaTeX listings package */
|
||
pre.src-ada:before { content: 'Ada'; }
|
||
pre.src-asm:before { content: 'Assembler'; }
|
||
pre.src-caml:before { content: 'Caml'; }
|
||
pre.src-delphi:before { content: 'Delphi'; }
|
||
pre.src-html:before { content: 'HTML'; }
|
||
pre.src-idl:before { content: 'IDL'; }
|
||
pre.src-mercury:before { content: 'Mercury'; }
|
||
pre.src-metapost:before { content: 'MetaPost'; }
|
||
pre.src-modula-2:before { content: 'Modula-2'; }
|
||
pre.src-pascal:before { content: 'Pascal'; }
|
||
pre.src-ps:before { content: 'PostScript'; }
|
||
pre.src-prolog:before { content: 'Prolog'; }
|
||
pre.src-simula:before { content: 'Simula'; }
|
||
pre.src-tcl:before { content: 'tcl'; }
|
||
pre.src-tex:before { content: 'TeX'; }
|
||
pre.src-plain-tex:before { content: 'Plain TeX'; }
|
||
pre.src-verilog:before { content: 'Verilog'; }
|
||
pre.src-vhdl:before { content: 'VHDL'; }
|
||
pre.src-xml:before { content: 'XML'; }
|
||
pre.src-nxml:before { content: 'XML'; }
|
||
/* add a generic configuration mode; LaTeX export needs an additional
|
||
(add-to-list 'org-latex-listings-langs '(conf " ")) in .emacs */
|
||
pre.src-conf:before { content: 'Configuration File'; }
|
||
|
||
table { border-collapse:collapse; }
|
||
caption.t-above { caption-side: top; }
|
||
caption.t-bottom { caption-side: bottom; }
|
||
td, th { vertical-align:top; }
|
||
th.org-right { text-align: center; }
|
||
th.org-left { text-align: center; }
|
||
th.org-center { text-align: center; }
|
||
td.org-right { text-align: right; }
|
||
td.org-left { text-align: left; }
|
||
td.org-center { text-align: center; }
|
||
dt { font-weight: bold; }
|
||
.footpara { display: inline; }
|
||
.footdef { margin-bottom: 1em; }
|
||
.figure { padding: 1em; }
|
||
.figure p { text-align: center; }
|
||
.equation-container {
|
||
display: table;
|
||
text-align: center;
|
||
width: 100%;
|
||
}
|
||
.equation {
|
||
vertical-align: middle;
|
||
}
|
||
.equation-label {
|
||
display: table-cell;
|
||
text-align: right;
|
||
vertical-align: middle;
|
||
}
|
||
.inlinetask {
|
||
padding: 10px;
|
||
border: 2px solid gray;
|
||
margin: 10px;
|
||
background: #ffffcc;
|
||
}
|
||
#org-div-home-and-up
|
||
{ text-align: right; font-size: 70%; white-space: nowrap; }
|
||
textarea { overflow-x: auto; }
|
||
.linenr { font-size: smaller }
|
||
.code-highlighted { background-color: #ffff00; }
|
||
.org-info-js_info-navigation { border-style: none; }
|
||
#org-info-js_console-label
|
||
{ font-size: 10px; font-weight: bold; white-space: nowrap; }
|
||
.org-info-js_search-highlight
|
||
{ background-color: #ffff00; color: #000000; font-weight: bold; }
|
||
.org-svg { width: 90%; }
|
||
</style>
|
||
<link rel="stylesheet" type="text/css" href="org-html-themes/src/readtheorg_theme/css/htmlize.css"/>
|
||
<link rel="stylesheet" type="text/css" href="org-html-themes/src/readtheorg_theme/css/readtheorg.css"/>
|
||
<script src="httpss://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script>
|
||
<script src="httpss://maxcdn.bootstrapcdn.com/bootstrap/3.3.4/js/bootstrap.min.js"></script>
|
||
<script type="text/javascript" src="org-html-themes/src/lib/js/jquery.stickytableheaders.min.js"></script>
|
||
<script type="text/javascript" src="org-html-themes/src/readtheorg_theme/js/readtheorg.js"></script>
|
||
<link rel="stylesheet" type="text/css" href="org-html-themes/src/readtheorg_theme/css/htmlize.css"/>
|
||
<link rel="stylesheet" type="text/css" href="org-html-themes/src/readtheorg_theme/css/readtheorg.css"/>
|
||
<script src="httpss://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script>
|
||
<script src="httpss://maxcdn.bootstrapcdn.com/bootstrap/3.3.4/js/bootstrap.min.js"></script>
|
||
<script type="text/javascript" src="org-html-themes/src/lib/js/jquery.stickytableheaders.min.js"></script>
|
||
<script type="text/javascript" src="org-html-themes/src/readtheorg_theme/js/readtheorg.js"></script>
|
||
<link rel="stylesheet" type="text/css" href="org-html-themes/src/readtheorg_theme/css/htmlize.css"/>
|
||
<link rel="stylesheet" type="text/css" href="org-html-themes/src/readtheorg_theme/css/readtheorg.css"/>
|
||
<script src="httpss://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script>
|
||
<script src="httpss://maxcdn.bootstrapcdn.com/bootstrap/3.3.4/js/bootstrap.min.js"></script>
|
||
<script type="text/javascript" src="org-html-themes/src/lib/js/jquery.stickytableheaders.min.js"></script>
|
||
<script type="text/javascript" src="org-html-themes/src/readtheorg_theme/js/readtheorg.js"></script>
|
||
<script type="text/x-mathjax-config">
|
||
MathJax.Hub.Config({
|
||
displayAlign: "center",
|
||
displayIndent: "0em",
|
||
|
||
"HTML-CSS": { scale: 100,
|
||
linebreaks: { automatic: "false" },
|
||
webFont: "TeX"
|
||
},
|
||
SVG: {scale: 100,
|
||
linebreaks: { automatic: "false" },
|
||
font: "TeX"},
|
||
NativeMML: {scale: 100},
|
||
TeX: { equationNumbers: {autoNumber: "AMS"},
|
||
MultLineWidth: "85%",
|
||
TagSide: "right",
|
||
TagIndent: ".8em"
|
||
}
|
||
});
|
||
</script>
|
||
<script src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS_HTML"></script>
|
||
</head>
|
||
<body>
|
||
<div id="content" class="content">
|
||
<h1 class="title">find</h1>
|
||
<div id="table-of-contents" role="doc-toc">
|
||
<h2>Table of Contents</h2>
|
||
<div id="text-table-of-contents" role="doc-toc">
|
||
<ul>
|
||
<li><a href="#org0b0a1db">NAME</a></li>
|
||
<li><a href="#org91b41dc">SYNOPSIS</a></li>
|
||
<li><a href="#orgef83683">TLDR</a></li>
|
||
<li><a href="#org01a3f80">DESCRIPTION</a></li>
|
||
<li><a href="#org2db8a12">OPTIONS</a></li>
|
||
<li><a href="#org123c3e1">EXPRESSION</a>
|
||
<ul>
|
||
<li><a href="#org882c16c">POSITIONAL OPTIONS</a></li>
|
||
<li><a href="#orgba13388">GLOBAL OPTIONS</a></li>
|
||
<li><a href="#org161a06f">TESTS</a></li>
|
||
<li><a href="#orgc8e29cf">ACTIONS</a></li>
|
||
<li><a href="#org5523b97">OPERATORS</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#org21a7342">UNUSUAL FILENAMES</a></li>
|
||
<li><a href="#orgfe44b9c">STANDARDS CONFORMANCE</a></li>
|
||
<li><a href="#org64c6aa7">ENVIRONMENT VARIABLES</a></li>
|
||
<li><a href="#orgd4763a7">EXAMPLES</a>
|
||
<ul>
|
||
<li><a href="#org0307417">Simple `find|xargs` approach</a></li>
|
||
<li><a href="#org29219f8">Safer `find -print0 | xargs -0` approach</a></li>
|
||
<li><a href="#org4ed62ec">Executing a command for each file</a></li>
|
||
<li><a href="#org9f299cf">Traversing the filesystem just once - for 2 different actions</a></li>
|
||
<li><a href="#orgf6fd0a8">Searching files by age</a></li>
|
||
<li><a href="#org31063bf">Searching files by permissions</a></li>
|
||
<li><a href="#orgb7c0ca9">Pruning - omitting files and subdirectories</a></li>
|
||
<li><a href="#org177a409">Other useful examples</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#org00806f3">EXIT STATUS</a></li>
|
||
<li><a href="#orgabb7b5a">HISTORY</a></li>
|
||
<li><a href="#org276a566">NON-BUGS</a>
|
||
<ul>
|
||
<li><a href="#orgd2b2f71">Operator precedence surprises</a></li>
|
||
<li><a href="#orga0a531c">“paths must precede expression” error message</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#org8a4cbb8">BUGS</a></li>
|
||
<li><a href="#orga84f7d6">REPORTING BUGS</a></li>
|
||
<li><a href="#orgbae495c">COPYRIGHT</a></li>
|
||
<li><a href="#org1bcb8eb">SEE ALSO</a></li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<div class="orgyeah-header">
|
||
<img src="logo.png"/>
|
||
<div class="topbar-menu-container">
|
||
<span class="topbar-menu"><a class="current" href="index.html">Home</a></span>
|
||
<span class="topbar-menu"><a href="dtos/index.html">Linux Manpages</a></span>
|
||
<span class="topbar-menu"><a href="contribute/index.html">Linux Software</a></span>
|
||
<span class="topbar-menu"><a href="kb/index.html">Linux Wiki</a></span>
|
||
<span class="topbar-menu"><a href="community/index.html">Bash Wiki</a></span>
|
||
<span class="topbar-menu"><a href="contribute/index.html">Emacs Wiki</a></span>
|
||
<span class="topbar-menu"><a href="contribute/index.html">Contribute</a></span>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org0b0a1db" class="outline-2">
|
||
<h2 id="org0b0a1db">NAME</h2>
|
||
<div class="outline-text-2" id="text-org0b0a1db">
|
||
<p>
|
||
find - search for files in a directory hierarchy
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org91b41dc" class="outline-2">
|
||
<h2 id="org91b41dc">SYNOPSIS</h2>
|
||
<div class="outline-text-2" id="text-org91b41dc">
|
||
<p>
|
||
<b>find</b> [-H] [-L] [-P] [-D debugopts] [-Olevel] [starting-point…]
|
||
[expression]
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-orgef83683" class="outline-2">
|
||
<h2 id="orgef83683">TLDR</h2>
|
||
<div class="outline-text-2" id="text-orgef83683">
|
||
<p>
|
||
The examples in the table below are from tldr-pages project: <a href="https://tldr.sh">https://tldr.sh</a>
|
||
</p>
|
||
<pre class="example" id="org1bf9a90">
|
||
- Find files by extension:
|
||
find root_path -name '*.ext'
|
||
|
||
- Find files matching multiple path/name patterns:
|
||
find root_path -path '**/path/**/*.ext' -or -name '*pattern*'
|
||
|
||
- Find directories matching a given name, in case-insensitive mode:
|
||
find root_path -type d -iname '*lib*'
|
||
|
||
- Find files matching a given pattern, excluding specific paths:
|
||
find root_path -name '*.py' -not -path '*/site-packages/*'
|
||
|
||
- Find files matching a given size range:
|
||
find root_path -size +500k -size -10M
|
||
|
||
- Run a command for each file (use `{}` within the command to access the filename):
|
||
find root_path -name '*.ext' -exec wc -l {} \;
|
||
|
||
- Find files modified in the last 7 days and delete them:
|
||
find root_path -daystart -mtime -7 -delete
|
||
|
||
- Find empty (0 byte) files and delete them:
|
||
find root_path -type f -empty -delete
|
||
</pre>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org01a3f80" class="outline-2">
|
||
<h2 id="org01a3f80">DESCRIPTION</h2>
|
||
<div class="outline-text-2" id="text-org01a3f80">
|
||
<p>
|
||
This manual page documents the GNU version of <b>find</b>. GNU <b>find</b>
|
||
searches the directory tree rooted at each given starting-point by
|
||
evaluating the given expression from left to right, according to the
|
||
rules of precedence (see section OPERATORS), until the outcome is known
|
||
(the left hand side is false for <i>and</i> operations, true for <i>or</i>), at
|
||
which point <b>find</b> moves on to the next file name. If no starting-point
|
||
is specified, `.’ is assumed.
|
||
</p>
|
||
|
||
<p>
|
||
If you are using <b>find</b> in an environment where security is important
|
||
(for example if you are using it to search directories that are writable
|
||
by other users), you should read the `Security Considerations’ chapter
|
||
of the findutils documentation, which is called <b>Finding Files</b> and
|
||
comes with findutils. That document also includes a lot more detail and
|
||
discussion than this manual page, so you may find it a more useful
|
||
source of information.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org2db8a12" class="outline-2">
|
||
<h2 id="org2db8a12">OPTIONS</h2>
|
||
<div class="outline-text-2" id="text-org2db8a12">
|
||
<p>
|
||
The <b>-H</b>, <b>-L</b> and <b>-P</b> options control the treatment of symbolic links.
|
||
Command-line arguments following these are taken to be names of files or
|
||
directories to be examined, up to the first argument that begins with
|
||
`-’, or the argument `(’ or `!’. That argument and any following
|
||
arguments are taken to be the expression describing what is to be
|
||
searched for. If no paths are given, the current directory is used. If
|
||
no expression is given, the expression <b>-print</b> is used (but you should
|
||
probably consider using <b>-print0</b> instead, anyway).
|
||
</p>
|
||
|
||
<p>
|
||
This manual page talks about `options’ within the expression list. These
|
||
options control the behaviour of <b>find</b> but are specified immediately
|
||
after the last path name. The five `real’ options <b>-H</b>, <b>-L</b>, <b>-P</b>, <b>-D</b>
|
||
and <b>-O</b> must appear before the first path name, if at all. A double
|
||
dash <b>--</b> could theoretically be used to signal that any remaining
|
||
arguments are not options, but this does not really work due to the way
|
||
<b>find</b> determines the end of the following path arguments: it does that
|
||
by reading until an expression argument comes (which also starts with a
|
||
`-’). Now, if a path argument would start with a `-’, then <b>find</b> would
|
||
treat it as expression argument instead. Thus, to ensure that all start
|
||
points are taken as such, and especially to prevent that wildcard
|
||
patterns expanded by the calling shell are not mistakenly treated as
|
||
expression arguments, it is generally safer to prefix wildcards or
|
||
dubious path names with either `./’ or to use absolute path names
|
||
starting with ’/’.
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>-P</dt><dd>Never follow symbolic links. This is the default behaviour. When
|
||
<b>find</b> examines or prints information about files, and the file is a
|
||
symbolic link, the information used shall be taken from the properties
|
||
of the symbolic link itself.</dd>
|
||
|
||
<dt>-L</dt><dd><p>
|
||
Follow symbolic links. When <b>find</b> examines or prints
|
||
information about files, the information used shall be taken from the
|
||
properties of the file to which the link points, not from the link
|
||
itself (unless it is a broken symbolic link or <b>find</b> is unable to
|
||
examine the file to which the link points). Use of this option implies
|
||
<b>-noleaf</b>. If you later use the <b>-P</b> option, <b>-noleaf</b> will still be
|
||
in effect. If <b>-L</b> is in effect and <b>find</b> discovers a symbolic link
|
||
to a subdirectory during its search, the subdirectory pointed to by
|
||
the symbolic link will be searched.
|
||
</p>
|
||
|
||
<p>
|
||
When the <b>-L</b> option is in effect, the <b>-type</b> predicate will always
|
||
match against the type of the file that a symbolic link points to
|
||
rather than the link itself (unless the symbolic link is broken).
|
||
Actions that can cause symbolic links to become broken while <b>find</b> is
|
||
executing (for example <b>-delete</b>) can give rise to confusing
|
||
behaviour. Using <b>-L</b> causes the <b>-lname</b> and <b>-ilname</b> predicates
|
||
always to return false.
|
||
</p></dd>
|
||
|
||
<dt>-H</dt><dd>Do not follow symbolic links, except while processing the
|
||
command line arguments. When <b>find</b> examines or prints information
|
||
about files, the information used shall be taken from the properties
|
||
of the symbolic link itself. The only exception to this behaviour is
|
||
when a file specified on the command line is a symbolic link, and the
|
||
link can be resolved. For that situation, the information used is
|
||
taken from whatever the link points to (that is, the link is
|
||
followed). The information about the link itself is used as a fallback
|
||
if the file pointed to by the symbolic link cannot be examined. If
|
||
<b>-H</b> is in effect and one of the paths specified on the command line
|
||
is a symbolic link to a directory, the contents of that directory will
|
||
be examined (though of course <b>-maxdepth 0</b> would prevent this).</dd>
|
||
</dl>
|
||
|
||
<p>
|
||
If more than one of <b>-H</b>, <b>-L</b> and <b>-P</b> is specified, each overrides the
|
||
others; the last one appearing on the command line takes effect. Since
|
||
it is the default, the <b>-P</b> option should be considered to be in effect
|
||
unless either <b>-H</b> or <b>-L</b> is specified.
|
||
</p>
|
||
|
||
<p>
|
||
GNU <b>find</b> frequently stats files during the processing of the command
|
||
line itself, before any searching has begun. These options also affect
|
||
how those arguments are processed. Specifically, there are a number of
|
||
tests that compare files listed on the command line against a file we
|
||
are currently considering. In each case, the file specified on the
|
||
command line will have been examined and some of its properties will
|
||
have been saved. If the named file is in fact a symbolic link, and the
|
||
<b>-P</b> option is in effect (or if neither <b>-H</b> nor <b>-L</b> were specified),
|
||
the information used for the comparison will be taken from the
|
||
properties of the symbolic link. Otherwise, it will be taken from the
|
||
properties of the file the link points to. If <b>find</b> cannot follow the
|
||
link (for example because it has insufficient privileges or the link
|
||
points to a nonexistent file) the properties of the link itself will be
|
||
used.
|
||
</p>
|
||
|
||
<p>
|
||
When the <b>-H</b> or <b>-L</b> options are in effect, any symbolic links listed
|
||
as the argument of <b>-newer</b> will be dereferenced, and the timestamp will
|
||
be taken from the file to which the symbolic link points. The same
|
||
consideration applies to <b>-newerXY</b>, <b>-anewer</b> and <b>-cnewer</b>.
|
||
</p>
|
||
|
||
<p>
|
||
The <b>-follow</b> option has a similar effect to <b>-L</b>, though it takes
|
||
effect at the point where it appears (that is, if <b>-L</b> is not used but
|
||
<b>-follow</b> is, any symbolic links appearing after <b>-follow</b> on the
|
||
command line will be dereferenced, and those before it will not).
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>-D debugopts</dt><dd>Print diagnostic information; this can be helpful to
|
||
diagnose problems with why <b>find</b> is not doing what you want. The list
|
||
of debug options should be comma separated. Compatibility of the debug
|
||
options is not guaranteed between releases of findutils. For a
|
||
complete list of valid debug options, see the output of <b>find -D
|
||
help</b>. Valid debug options include
|
||
|
||
<dl class="org-dl">
|
||
<dt>exec</dt><dd>Show diagnostic information relating to -exec, -execdir, -ok
|
||
and -okdir</dd>
|
||
|
||
<dt>opt</dt><dd>Prints diagnostic information relating to the optimisation of
|
||
the expression tree; see the -O option.</dd>
|
||
|
||
<dt>rates</dt><dd>Prints a summary indicating how often each predicate
|
||
succeeded or failed.</dd>
|
||
|
||
<dt>search</dt><dd>Navigate the directory tree verbosely.</dd>
|
||
|
||
<dt>stat</dt><dd>Print messages as files are examined with the <b>stat</b> and
|
||
<b>lstat</b> system calls. The <b>find</b> program tries to minimise such
|
||
calls.</dd>
|
||
|
||
<dt>tree</dt><dd>Show the expression tree in its original and optimised form.</dd>
|
||
|
||
<dt>all</dt><dd>Enable all of the other debug options (but <b>help</b>).</dd>
|
||
|
||
<dt>help</dt><dd>Explain the debugging options.</dd>
|
||
</dl></dd>
|
||
|
||
<dt>-Olevel</dt><dd><p>
|
||
Enables query optimisation. The <b>find</b> program reorders
|
||
tests to speed up execution while preserving the overall effect; that
|
||
is, predicates with side effects are not reordered relative to each
|
||
other. The optimisations performed at each optimisation level are as
|
||
follows.
|
||
</p>
|
||
|
||
<ol class="org-ol">
|
||
<li>Equivalent to optimisation level 1.</li>
|
||
|
||
<li>This is the default optimisation level and corresponds to the
|
||
traditional behaviour. Expressions are reordered so that tests
|
||
based only on the names of files (for example <b>-name</b> and <b>-regex</b>)
|
||
are performed first.</li>
|
||
|
||
<li>Any <b>-type</b> or <b>-xtype</b> tests are performed after any tests based
|
||
only on the names of files, but before any tests that require
|
||
information from the inode. On many modern versions of Unix, file
|
||
types are returned by <b>readdir()</b> and so these predicates are
|
||
faster to evaluate than predicates which need to stat the file
|
||
first. If you use the <b>-fstype <i>FOO</i></b> predicate and specify a
|
||
filesystem type <i>FOO</i> which is not known (that is, present in
|
||
`/etc/mtab’) at the time <b>find</b> starts, that predicate is
|
||
equivalent to <b>-false</b>.</li>
|
||
|
||
<li>At this optimisation level, the full cost-based query optimiser is
|
||
enabled. The order of tests is modified so that cheap (i.e. fast)
|
||
tests are performed first and more expensive ones are performed
|
||
later, if necessary. Within each cost band, predicates are
|
||
evaluated earlier or later according to whether they are likely to
|
||
succeed or not. For <b>-o</b>, predicates which are likely to succeed
|
||
are evaluated earlier, and for <b>-a</b>, predicates which are likely to
|
||
fail are evaluated earlier.</li>
|
||
</ol>
|
||
|
||
<p>
|
||
The cost-based optimiser has a fixed idea of how likely any given test
|
||
is to succeed. In some cases the probability takes account of the
|
||
specific nature of the test (for example, <b>-type f</b> is assumed to be
|
||
more likely to succeed than <b>-type c</b>). The cost-based optimiser is
|
||
currently being evaluated. If it does not actually improve the
|
||
performance of <b>find</b>, it will be removed again. Conversely,
|
||
optimisations that prove to be reliable, robust and effective may be
|
||
enabled at lower optimisation levels over time. However, the default
|
||
behaviour (i.e. optimisation level 1) will not be changed in the 4.3.x
|
||
release series. The findutils test suite runs all the tests on <b>find</b>
|
||
at each optimisation level and ensures that the result is the same.
|
||
</p></dd>
|
||
</dl>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org123c3e1" class="outline-2">
|
||
<h2 id="org123c3e1">EXPRESSION</h2>
|
||
<div class="outline-text-2" id="text-org123c3e1">
|
||
<p>
|
||
The part of the command line after the list of starting points is the
|
||
<i>expression</i>. This is a kind of query specification describing how we
|
||
match files and what we do with the files that were matched. An
|
||
expression is composed of a sequence of things:
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>Tests</dt><dd>Tests return a true or false value, usually on the basis of
|
||
some property of a file we are considering. The <b>-empty</b> test for
|
||
example is true only when the current file is empty.</dd>
|
||
|
||
<dt>Actions</dt><dd>Actions have side effects (such as printing something on
|
||
the standard output) and return either true or false, usually based on
|
||
whether or not they are successful. The <b>-print</b> action for example
|
||
prints the name of the current file on the standard output.</dd>
|
||
|
||
<dt>Global options</dt><dd>Global options affect the operation of tests and
|
||
actions specified on any part of the command line. Global options
|
||
always return true. The <b>-depth</b> option for example makes <b>find</b>
|
||
traverse the file system in a depth-first order.</dd>
|
||
|
||
<dt>Positional options</dt><dd>Positional options affect only tests or actions
|
||
which follow them. Positional options always return true. The
|
||
<b>-regextype</b> option for example is positional, specifying the regular
|
||
expression dialect for regular expressions occurring later on the
|
||
command line.</dd>
|
||
|
||
<dt>Operators</dt><dd>Operators join together the other items within the
|
||
expression. They include for example <b>-o</b> (meaning logical OR) and
|
||
<b>-a</b> (meaning logical AND). Where an operator is missing, <b>-a</b> is
|
||
assumed.</dd>
|
||
</dl>
|
||
|
||
<p>
|
||
The <b>-print</b> action is performed on all files for which the whole
|
||
expression is true, unless it contains an action other than <b>-prune</b> or
|
||
<b>-quit</b>. Actions which inhibit the default <b>-print</b> are <b>-delete</b>,
|
||
<b>-exec</b>, <b>-execdir</b>, <b>-ok</b>, <b>-okdir</b>, <b>-fls</b>, <b>-fprint</b>, <b>-fprintf</b>,
|
||
<b>-ls</b>, <b>-print</b> and <b>-printf</b>.
|
||
</p>
|
||
|
||
<p>
|
||
The <b>-delete</b> action also acts like an option (since it implies
|
||
<b>-depth</b>).
|
||
</p>
|
||
</div>
|
||
|
||
<div id="outline-container-org882c16c" class="outline-3">
|
||
<h3 id="org882c16c">POSITIONAL OPTIONS</h3>
|
||
<div class="outline-text-3" id="text-org882c16c">
|
||
<p>
|
||
Positional options always return true. They affect only tests occurring
|
||
later on the command line.
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>-daystart</dt><dd>Measure times (for <b>-amin</b>, <b>-atime</b>, <b>-cmin</b>, <b>-ctime</b>,
|
||
<b>-mmin</b>, and <b>-mtime</b>) from the beginning of today rather than from 24
|
||
hours ago. This option only affects tests which appear later on the
|
||
command line.</dd>
|
||
|
||
<dt>-follow</dt><dd>Deprecated; use the <b>-L</b> option instead. Dereference
|
||
symbolic links. Implies <b>-noleaf</b>. The <b>-follow</b> option affects only
|
||
those tests which appear after it on the command line. Unless the <b>-H</b>
|
||
or <b>-L</b> option has been specified, the position of the <b>-follow</b>
|
||
option changes the behaviour of the <b>-newer</b> predicate; any files
|
||
listed as the argument of <b>-newer</b> will be dereferenced if they are
|
||
symbolic links. The same consideration applies to <b>-newerXY</b>,
|
||
<b>-anewer</b> and <b>-cnewer</b>. Similarly, the <b>-type</b> predicate will always
|
||
match against the type of the file that a symbolic link points to
|
||
rather than the link itself. Using <b>-follow</b> causes the <b>-lname and</b>
|
||
<b>-ilname</b> predicates always to return false.</dd>
|
||
|
||
<dt>-regextype type</dt><dd>Changes the regular expression syntax understood by
|
||
<b>-regex</b> and <b>-iregex</b> tests which occur later on the command line. To
|
||
see which regular expression types are known, use <b>-regextype help</b>.
|
||
The Texinfo documentation (see <b>SEE</b> <b>ALSO</b>) explains the meaning of
|
||
and differences between the various types of regular expression.</dd>
|
||
|
||
<dt>-warn, -nowarn</dt><dd>Turn warning messages on or off. These warnings
|
||
apply only to the command line usage, not to any conditions that
|
||
<b>find</b> might encounter when it searches directories. The default
|
||
behaviour corresponds to <b>-warn</b> if standard input is a tty, and to
|
||
<b>-nowarn</b> otherwise. If a warning message relating to command-line
|
||
usage is produced, the exit status of <b>find</b> is not affected. If the
|
||
POSIXLY_CORRECT environment variable is set, and <b>-warn</b> is also used,
|
||
it is not specified which, if any, warnings will be active.</dd>
|
||
</dl>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-orgba13388" class="outline-3">
|
||
<h3 id="orgba13388">GLOBAL OPTIONS</h3>
|
||
<div class="outline-text-3" id="text-orgba13388">
|
||
<p>
|
||
Global options always return true. Global options take effect even for
|
||
tests which occur earlier on the command line. To prevent confusion,
|
||
global options should specified on the command-line after the list of
|
||
start points, just before the first test, positional option or action.
|
||
If you specify a global option in some other place, <b>find</b> will issue a
|
||
warning message explaining that this can be confusing.
|
||
</p>
|
||
|
||
<p>
|
||
The global options occur after the list of start points, and so are not
|
||
the same kind of option as <b>-L</b>, for example.
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>-d</dt><dd>A synonym for -depth, for compatibility with FreeBSD, NetBSD,
|
||
MacOS X and OpenBSD.</dd>
|
||
|
||
<dt>-depth</dt><dd>Process each directory’s contents before the directory
|
||
itself. The -delete action also implies <b>-depth</b>.</dd>
|
||
|
||
<dt>-help, –help</dt><dd>Print a summary of the command-line usage of <b>find</b>
|
||
and exit.</dd>
|
||
|
||
<dt>-ignore_readdir_race</dt><dd>Normally, <b>find</b> will emit an error message
|
||
when it fails to stat a file. If you give this option and a file is
|
||
deleted between the time <b>find</b> reads the name of the file from the
|
||
directory and the time it tries to stat the file, no error message
|
||
will be issued. This also applies to files or directories whose names
|
||
are given on the command line. This option takes effect at the time
|
||
the command line is read, which means that you cannot search one part
|
||
of the filesystem with this option on and part of it with this option
|
||
off (if you need to do that, you will need to issue two <b>find</b>
|
||
commands instead, one with the option and one without it).</dd>
|
||
</dl>
|
||
|
||
<p>
|
||
Furthermore, <b>find</b> with the <b>-ignore_readdir_race</b> option will ignore
|
||
errors of the <b>-delete</b> action in the case the file has disappeared
|
||
since the parent directory was read: it will not output an error
|
||
diagnostic, and the return code of the <b>-delete</b> action will be true.
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>-maxdepth levels</dt><dd>Descend at most <i>levels</i> (a non-negative integer)
|
||
levels of directories below the starting-points. Using <b>-maxdepth 0</b>
|
||
means only apply the tests and actions to the starting-points
|
||
themselves.</dd>
|
||
|
||
<dt>-mindepth levels</dt><dd>Do not apply any tests or actions at levels less
|
||
than <i>levels</i> (a non-negative integer). Using <b>-mindepth 1</b> means
|
||
process all files except the starting-points.</dd>
|
||
|
||
<dt>-mount</dt><dd>Don’t descend directories on other filesystems. An alternate
|
||
name for <b>-xdev</b>, for compatibility with some other versions of
|
||
<b>find</b>.</dd>
|
||
|
||
<dt>-noignore_readdir_race</dt><dd>Turns off the effect of
|
||
<b>-ignore_readdir_race</b>.</dd>
|
||
|
||
<dt>-noleaf</dt><dd>Do not optimize by assuming that directories contain 2
|
||
fewer subdirectories than their hard link count. This option is needed
|
||
when searching filesystems that do not follow the Unix directory-link
|
||
convention, such as CD-ROM or MS-DOS filesystems or AFS volume mount
|
||
points. Each directory on a normal Unix filesystem has at least 2 hard
|
||
links: its name and its `.’ entry. Additionally, its subdirectories
|
||
(if any) each have a `..’ entry linked to that directory. When <b>find</b>
|
||
is examining a directory, after it has statted 2 fewer subdirectories
|
||
than the directory’s link count, it knows that the rest of the entries
|
||
in the directory are non-directories (`leaf’ files in the directory
|
||
tree). If only the files’ names need to be examined, there is no need
|
||
to stat them; this gives a significant increase in search speed.</dd>
|
||
|
||
<dt>-version, –version</dt><dd>Print the <b>find</b> version number and exit.</dd>
|
||
|
||
<dt>-xdev</dt><dd>Don’t descend directories on other filesystems.</dd>
|
||
</dl>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org161a06f" class="outline-3">
|
||
<h3 id="org161a06f">TESTS</h3>
|
||
<div class="outline-text-3" id="text-org161a06f">
|
||
<p>
|
||
Some tests, for example <b>-newerXY</b> and <b>-samefile</b>, allow comparison
|
||
between the file currently being examined and some reference file
|
||
specified on the command line. When these tests are used, the
|
||
interpretation of the reference file is determined by the options <b>-H</b>,
|
||
<b>-L</b> and <b>-P</b> and any previous <b>-follow</b>, but the reference file is only
|
||
examined once, at the time the command line is parsed. If the reference
|
||
file cannot be examined (for example, the <b>stat*(2) system call fails
|
||
for it), an error message is issued, and *find</b> exits with a nonzero
|
||
status.
|
||
</p>
|
||
|
||
<p>
|
||
A numeric argument <i>n</i> can be specified to tests (like <b>-amin</b>,
|
||
<b>-mtime</b>, <b>-gid</b>, <b>-inum</b>, <b>-links</b>, <b>-size</b>, <b>-uid</b> and <b>-used</b>) as
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>+n</dt><dd>for greater than <i>n</i>,</dd>
|
||
|
||
<dt>-n</dt><dd>for less than <i>n</i>,</dd>
|
||
|
||
<dt>(no term)</dt><dd>for exactly <i>n</i>.</dd>
|
||
</dl>
|
||
|
||
<p>
|
||
Supported tests:
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>-amin n</dt><dd>File was last accessed less than, more than or exactly <i>n</i>
|
||
minutes ago.</dd>
|
||
|
||
<dt>-anewer reference</dt><dd>Time of the last access of the current file is
|
||
more recent than that of the last data modification of the <i>reference</i>
|
||
file. If <i>reference</i> is a symbolic link and the <b>-H</b> option or the
|
||
<b>-L</b> option is in effect, then the time of the last data modification
|
||
of the file it points to is always used.</dd>
|
||
|
||
<dt>-atime n</dt><dd>File was last accessed less than, more than or exactly
|
||
/n/*24 hours ago. When find figures out how many 24-hour periods ago
|
||
the file was last accessed, any fractional part is ignored, so to
|
||
match <b>-atime +1</b>, a file has to have been accessed at least <i>two</i>
|
||
days ago.</dd>
|
||
|
||
<dt>-cmin n</dt><dd>File’s status was last changed less than, more than or
|
||
exactly <i>n</i> minutes ago.</dd>
|
||
|
||
<dt>-cnewer reference</dt><dd>Time of the last status change of the current
|
||
file is more recent than that of the last data modification of the
|
||
<i>reference</i> file. If <i>reference</i> is a symbolic link and the <b>-H</b>
|
||
option or the <b>-L</b> option is in effect, then the time of the last data
|
||
modification of the file it points to is always used.</dd>
|
||
|
||
<dt>-ctime n</dt><dd>File’s status was last changed less than, more than or
|
||
exactly /n/*24 hours ago. See the comments for <b>-atime</b> to understand
|
||
how rounding affects the interpretation of file status change times.</dd>
|
||
|
||
<dt>-empty</dt><dd>File is empty and is either a regular file or a directory.</dd>
|
||
|
||
<dt>-executable</dt><dd>Matches files which are executable and directories
|
||
which are searchable (in a file name resolution sense) by the current
|
||
user. This takes into account access control lists and other
|
||
permissions artefacts which the <b>-perm</b> test ignores. This test makes
|
||
use of the *access*(2) system call, and so can be fooled by NFS
|
||
servers which do UID mapping (or root-squashing), since many systems
|
||
implement *access*(2) in the client’s kernel and so cannot make use of
|
||
the UID mapping information held on the server. Because this test is
|
||
based only on the result of the *access*(2) system call, there is no
|
||
guarantee that a file for which this test succeeds can actually be
|
||
executed.</dd>
|
||
|
||
<dt>-false</dt><dd>Always false.</dd>
|
||
|
||
<dt>-fstype type</dt><dd>File is on a filesystem of type <i>type</i>. The valid
|
||
filesystem types vary among different versions of Unix; an incomplete
|
||
list of filesystem types that are accepted on some version of Unix or
|
||
another is: ufs, 4.2, 4.3, nfs, tmp, mfs, S51K, S52K. You can use
|
||
<b>-printf</b> with the %F directive to see the types of your filesystems.</dd>
|
||
|
||
<dt>-gid n</dt><dd>File’s numeric group ID is less than, more than or exactly
|
||
<i>n</i>.</dd>
|
||
|
||
<dt>-group gname</dt><dd>File belongs to group <i>gname</i> (numeric group ID
|
||
allowed).</dd>
|
||
|
||
<dt>-ilname pattern</dt><dd>Like <b>-lname</b>, but the match is case insensitive.
|
||
If the <b>-L</b> option or the <b>-follow</b> option is in effect, this test
|
||
returns false unless the symbolic link is broken.</dd>
|
||
|
||
<dt>-iname pattern</dt><dd>Like <b>-name</b>, but the match is case insensitive. For
|
||
example, the patterns `fo*’ and `F??’ match the file names `Foo’,
|
||
`FOO’, `foo’, `fOo’, etc. The pattern `*foo*` will also match a file
|
||
called ’.foobar’.</dd>
|
||
|
||
<dt>-inum n</dt><dd>File has inode number smaller than, greater than or exactly
|
||
<i>n</i>. It is normally easier to use the <b>-samefile</b> test instead.</dd>
|
||
|
||
<dt>-ipath pattern</dt><dd>Like <b>-path</b>. but the match is case insensitive.</dd>
|
||
|
||
<dt>-iregex pattern</dt><dd>Like <b>-regex</b>, but the match is case insensitive.</dd>
|
||
|
||
<dt>-iwholename pattern</dt><dd>See -ipath. This alternative is less portable
|
||
than <b>-ipath</b>.</dd>
|
||
|
||
<dt>-links n</dt><dd>File has less than, more than or exactly <i>n</i> hard links.</dd>
|
||
|
||
<dt>-lname pattern</dt><dd>File is a symbolic link whose contents match shell
|
||
pattern <i>pattern</i>. The metacharacters do not treat `/’ or `.’
|
||
specially. If the <b>-L</b> option or the <b>-follow</b> option is in effect,
|
||
this test returns false unless the symbolic link is broken.</dd>
|
||
|
||
<dt>-mmin n</dt><dd>File’s data was last modified less than, more than or
|
||
exactly <i>n</i> minutes ago.</dd>
|
||
|
||
<dt>-mtime n</dt><dd>File’s data was last modified less than, more than or
|
||
exactly /n/*24 hours ago. See the comments for <b>-atime</b> to understand
|
||
how rounding affects the interpretation of file modification times.</dd>
|
||
|
||
<dt>-name pattern</dt><dd>Base of file name (the path with the leading
|
||
directories removed) matches shell pattern <i>pattern</i>. Because the
|
||
leading directories are removed, the file names considered for a match
|
||
with <b>-name</b> will never include a slash, so `-name a/b’ will never
|
||
match anything (you probably need to use <b>-path</b> instead). A warning
|
||
is issued if you try to do this, unless the environment variable
|
||
POSIXLY_CORRECT is set. The metacharacters (`*’, `?’, and `[]’) match
|
||
a `.’ at the start of the base name (this is a change in
|
||
findutils-4.2.2; see section STANDARDS CONFORMANCE below). To ignore a
|
||
directory and the files under it, use <b>-prune</b> rather than checking
|
||
every file in the tree; see an example in the description of that
|
||
action. Braces are not recognised as being special, despite the fact
|
||
that some shells including Bash imbue braces with a special meaning in
|
||
shell patterns. The filename matching is performed with the use of the
|
||
*fnmatch*(3) library function. Don’t forget to enclose the pattern in
|
||
quotes in order to protect it from expansion by the shell.</dd>
|
||
|
||
<dt>-newer reference</dt><dd>Time of the last data modification of the current
|
||
file is more recent than that of the last data modification of the
|
||
<i>reference</i> file. If <i>reference</i> is a symbolic link and the <b>-H</b>
|
||
option or the <b>-L</b> option is in effect, then the time of the last data
|
||
modification of the file it points to is always used.</dd>
|
||
|
||
<dt>-newerXY reference</dt><dd>Succeeds if timestamp <i>X</i> of the file being
|
||
considered is newer than timestamp <i>Y</i> of the file <i>reference</i>. The
|
||
letters <i>X</i> and <i>Y</i> can be any of the following letters:</dd>
|
||
</dl>
|
||
|
||
<table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">
|
||
|
||
|
||
<colgroup>
|
||
<col class="org-left" />
|
||
|
||
<col class="org-left" />
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td class="org-left">a</td>
|
||
<td class="org-left">The access time of the file <i>reference</i></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">B</td>
|
||
<td class="org-left">The birth time of the file <i>reference</i></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">c</td>
|
||
<td class="org-left">The inode status change time of <i>reference</i></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">m</td>
|
||
<td class="org-left">The modification time of the file <i>reference</i></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">t</td>
|
||
<td class="org-left"><i>reference</i> is interpreted directly as a time</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<p>
|
||
Some combinations are invalid; for example, it is invalid for <i>X</i> to be
|
||
<i>t</i>. Some combinations are not implemented on all systems; for example
|
||
<i>B</i> is not supported on all systems. If an invalid or unsupported
|
||
combination of <i>XY</i> is specified, a fatal error results. Time
|
||
specifications are interpreted as for the argument to the <b>-d</b> option of
|
||
GNU <b>date</b>. If you try to use the birth time of a reference file, and
|
||
the birth time cannot be determined, a fatal error message results. If
|
||
you specify a test which refers to the birth time of files being
|
||
examined, this test will fail for any files where the birth time is
|
||
unknown.
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>-nogroup</dt><dd>No group corresponds to file’s numeric group ID.</dd>
|
||
|
||
<dt>-nouser</dt><dd>No user corresponds to file’s numeric user ID.</dd>
|
||
|
||
<dt>-path pattern</dt><dd>File name matches shell pattern <i>pattern</i>. The
|
||
metacharacters do not treat `/’ or `.’ specially; so, for example,</dd>
|
||
</dl>
|
||
|
||
<pre class="example" id="org685946a">
|
||
find . -path "./sr*sc"
|
||
</pre>
|
||
|
||
<p>
|
||
will print an entry for a directory called <i>./src/misc</i> (if one exists).
|
||
To ignore a whole directory tree, use <b>-prune</b> rather than checking
|
||
every file in the tree. Note that the pattern match test applies to the
|
||
whole file name, starting from one of the start points named on the
|
||
command line. It would only make sense to use an absolute path name here
|
||
if the relevant start point is also an absolute path. This means that
|
||
this command will never match anything:<br />
|
||
</p>
|
||
|
||
<pre class="example" id="org5921ca8">
|
||
find bar -path /foo/bar/myfile -print
|
||
</pre>
|
||
|
||
<p>
|
||
Find compares the <b>-path</b> argument with the concatenation of a directory
|
||
name and the base name of the file it’s examining. Since the
|
||
concatenation will never end with a slash, <b>-path</b> arguments ending in a
|
||
slash will match nothing (except perhaps a start point specified on the
|
||
command line). The predicate <b>-path</b> is also supported by HP-UX <b>find</b>
|
||
and is part of the POSIX 2008 standard.
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>-perm mode</dt><dd>File’s permission bits are exactly <i>mode</i> (octal or
|
||
symbolic). Since an exact match is required, if you want to use this
|
||
form for symbolic modes, you may have to specify a rather complex mode
|
||
string. For example `-perm g=w’ will only match files which have mode
|
||
0020 (that is, ones for which group write permission is the only
|
||
permission set). It is more likely that you will want to use the `/’
|
||
or `-’ forms, for example `-perm -g=w’, which matches any file with
|
||
group write permission. See the <b>EXAMPLES</b> section for some
|
||
illustrative examples.</dd>
|
||
|
||
<dt>-perm -mode</dt><dd>All of the permission bits <i>mode</i> are set for the file.
|
||
Symbolic modes are accepted in this form, and this is usually the way
|
||
in which you would want to use them. You must specify `u’, `g’ or `o’
|
||
if you use a symbolic mode. See the <b>EXAMPLES</b> section for some
|
||
illustrative examples.</dd>
|
||
|
||
<dt>-perm /mode</dt><dd>Any of the permission bits <i>mode</i> are set for the file.
|
||
Symbolic modes are accepted in this form. You must specify `u’, `g’ or
|
||
`o’ if you use a symbolic mode. See the <b>EXAMPLES</b> section for some
|
||
illustrative examples. If no permission bits in <i>mode</i> are set, this
|
||
test matches any file (the idea here is to be consistent with the
|
||
behaviour of <b>-perm -000</b>).</dd>
|
||
|
||
<dt>-perm +mode</dt><dd>This is no longer supported (and has been deprecated
|
||
since 2005). Use <b>-perm <i>/mode</i></b> instead.</dd>
|
||
|
||
<dt>-readable</dt><dd>Matches files which are readable by the current user.
|
||
This takes into account access control lists and other permissions
|
||
artefacts which the <b>-perm</b> test ignores. This test makes use of the
|
||
*access*(2) system call, and so can be fooled by NFS servers which do
|
||
UID mapping (or root-squashing), since many systems implement
|
||
*access*(2) in the client’s kernel and so cannot make use of the UID
|
||
mapping information held on the server.</dd>
|
||
|
||
<dt>-regex pattern</dt><dd>File name matches regular expression <i>pattern</i>. This
|
||
is a match on the whole path, not a search. For example, to match a
|
||
file named <i>./fubar3,</i> you can use the regular expression `.*bar.’ or
|
||
`.*b.*3’, but not `f.*r3’. The regular expressions understood by
|
||
<b>find</b> are by default Emacs Regular Expressions (except that `.’
|
||
matches newline), but this can be changed with the <b>-regextype</b>
|
||
option.</dd>
|
||
|
||
<dt>-samefile name</dt><dd>File refers to the same inode as <i>name</i>. When <b>-L</b>
|
||
is in effect, this can include symbolic links.</dd>
|
||
|
||
<dt>-size n[cwbkMG]</dt><dd><p>
|
||
File uses less than, more than or exactly <i>n</i> units
|
||
of space, rounding up. The following suffixes can be used:
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>`b’</dt><dd>for 512-byte blocks (this is the default if no suffix is
|
||
used)</dd>
|
||
|
||
<dt>`c’</dt><dd>for bytes</dd>
|
||
|
||
<dt>`w’</dt><dd>for two-byte words</dd>
|
||
|
||
<dt>`k’</dt><dd>for kibibytes (KiB, units of 1024 bytes)</dd>
|
||
|
||
<dt>`M’</dt><dd>for mebibytes (MiB, units of 1024 * 1024 = 1 048 576 bytes)</dd>
|
||
|
||
<dt>`G’</dt><dd>for gibibytes (GiB, units of 1024 * 1024 * 1024 =
|
||
1 073 741 824 bytes)</dd>
|
||
</dl>
|
||
|
||
<p>
|
||
The size is simply the st_size member of the struct stat populated by
|
||
the lstat (or stat) system call, rounded up as shown above. In other
|
||
words, it’s consistent with the result you get for <b>ls -l</b>. Bear in
|
||
mind that the `%k’ and `%b’ format specifiers of <b>-printf</b> handle
|
||
sparse files differently. The `b’ suffix always denotes 512-byte
|
||
blocks and never 1024-byte blocks, which is different to the behaviour
|
||
of <b>-ls</b>.
|
||
</p>
|
||
|
||
<p>
|
||
The + and - prefixes signify greater than and less than, as usual;
|
||
i.e., an exact size of <i>n</i> units does not match. Bear in mind that the
|
||
size is rounded up to the next unit. Therefore <b>-size -1M</b> is not
|
||
equivalent to <b>-size -1 048 576c</b>. The former only matches empty
|
||
files, the latter matches files from 0 to 1,048,575 bytes.
|
||
</p></dd>
|
||
|
||
<dt>-true</dt><dd>Always true.</dd>
|
||
|
||
<dt>-type c</dt><dd><p>
|
||
File is of type <i>c</i>:
|
||
</p>
|
||
|
||
<ol class="org-ol">
|
||
<li>block (buffered) special</li>
|
||
|
||
<li>character (unbuffered) special</li>
|
||
|
||
<li>directory</li>
|
||
|
||
<li>named pipe (FIFO)</li>
|
||
|
||
<li>regular file</li>
|
||
|
||
<li>symbolic link; this is never true if the <b>-L</b> option or the
|
||
<b>-follow</b> option is in effect, unless the symbolic link is broken.
|
||
If you want to search for symbolic links when <b>-L</b> is in effect,
|
||
use <b>-xtype</b>.</li>
|
||
|
||
<li>socket</li>
|
||
|
||
<li>door (Solaris)</li>
|
||
</ol>
|
||
|
||
<p>
|
||
To search for more than one type at once, you can supply the combined
|
||
list of type letters separated by a comma `,’ (GNU extension).
|
||
</p></dd>
|
||
|
||
<dt>-uid n</dt><dd>File’s numeric user ID is less than, more than or exactly
|
||
<i>n</i>.</dd>
|
||
|
||
<dt>-used n</dt><dd>File was last accessed less than, more than or exactly <i>n</i>
|
||
days after its status was last changed.</dd>
|
||
|
||
<dt>-user uname</dt><dd>File is owned by user <i>uname</i> (numeric user ID
|
||
allowed).</dd>
|
||
|
||
<dt>-wholename pattern</dt><dd>See -path. This alternative is less portable
|
||
than <b>-path</b>.</dd>
|
||
|
||
<dt>-writable</dt><dd>Matches files which are writable by the current user.
|
||
This takes into account access control lists and other permissions
|
||
artefacts which the <b>-perm</b> test ignores. This test makes use of the
|
||
*access*(2) system call, and so can be fooled by NFS servers which do
|
||
UID mapping (or root-squashing), since many systems implement
|
||
*access*(2) in the client’s kernel and so cannot make use of the UID
|
||
mapping information held on the server.</dd>
|
||
|
||
<dt>-xtype c</dt><dd>The same as <b>-type</b> unless the file is a symbolic link.
|
||
For symbolic links: if the <b>-H</b> or <b>-P</b> option was specified, true if
|
||
the file is a link to a file of type <i>c</i>; if the <b>-L</b> option has been
|
||
given, true if <i>c</i> is `l’. In other words, for symbolic links,
|
||
<b>-xtype</b> checks the type of the file that <b>-type</b> does not check.</dd>
|
||
|
||
<dt>-context pattern</dt><dd>(SELinux only) Security context of the file
|
||
matches glob <i>pattern</i>.</dd>
|
||
</dl>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-orgc8e29cf" class="outline-3">
|
||
<h3 id="orgc8e29cf">ACTIONS</h3>
|
||
<div class="outline-text-3" id="text-orgc8e29cf">
|
||
<dl class="org-dl">
|
||
<dt>-delete</dt><dd>Delete files; true if removal succeeded. If the removal
|
||
failed, an error message is issued. If <b>-delete</b> fails, <b>find</b>’s exit
|
||
status will be nonzero (when it eventually exits). Use of <b>-delete</b>
|
||
automatically turns on the `*-depth*’ option.</dd>
|
||
</dl>
|
||
|
||
<p>
|
||
<b>Warnings</b>: Don’t forget that the find command line is evaluated as an
|
||
expression, so putting <b>-delete</b> first will make <b>find</b> try to delete
|
||
everything below the starting points you specified. When testing a
|
||
<b>find</b> command line that you later intend to use with <b>-delete</b>, you
|
||
should explicitly specify <b>-depth</b> in order to avoid later surprises.
|
||
Because <b>-delete</b> implies <b>-depth</b>, you cannot usefully use <b>-prune</b> and
|
||
<b>-delete</b> together.
|
||
</p>
|
||
|
||
<p>
|
||
Together with the <b>-ignore_readdir_race</b> option, <b>find</b> will ignore
|
||
errors of the <b>-delete</b> action in the case the file has disappeared
|
||
since the parent directory was read: it will not output an error
|
||
diagnostic, and the return code of the <b>-delete</b> action will be true.
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>-exec command ;</dt><dd>Execute <i>command</i>; true if 0 status is returned.
|
||
All following arguments to <b>find</b> are taken to be arguments to the
|
||
command until an argument consisting of `;’ is encountered. The string
|
||
`{}’ is replaced by the current file name being processed everywhere
|
||
it occurs in the arguments to the command, not just in arguments where
|
||
it is alone, as in some versions of <b>find</b>. Both of these
|
||
constructions might need to be escaped (with a `\’) or quoted to
|
||
protect them from expansion by the shell. See the <b>EXAMPLES</b> section
|
||
for examples of the use of the <b>-exec</b> option. The specified command
|
||
is run once for each matched file. The command is executed in the
|
||
starting directory. There are unavoidable security problems
|
||
surrounding use of the <b>-exec</b> action; you should use the <b>-execdir</b>
|
||
option instead.</dd>
|
||
|
||
<dt>-exec command {} +</dt><dd>This variant of the <b>-exec</b> action runs the
|
||
specified command on the selected files, but the command line is built
|
||
by appending each selected file name at the end; the total number of
|
||
invocations of the command will be much less than the number of
|
||
matched files. The command line is built in much the same way that
|
||
<b>xargs</b> builds its command lines. Only one instance of `{}’ is allowed
|
||
within the command, and it must appear at the end, immediately before
|
||
the `+’; it needs to be escaped (with a `\’) or quoted to protect it
|
||
from interpretation by the shell. The command is executed in the
|
||
starting directory. If any invocation with the `+’ form returns a
|
||
non-zero value as exit status, then <b>find</b> returns a non-zero exit
|
||
status. If <b>find</b> encounters an error, this can sometimes cause an
|
||
immediate exit, so some pending commands may not be run at all. For
|
||
this reason <b>-exec <i>my-command</i> … {} + -quit</b> may not result in
|
||
<i>my-command</i> actually being run. This variant of <b>-exec</b> always
|
||
returns true.</dd>
|
||
|
||
<dt>-execdir command ;</dt><dd></dd>
|
||
|
||
|
||
<dt>-execdir command {} +</dt><dd>Like <b>-exec</b>, but the specified command is
|
||
run from the subdirectory containing the matched file, which is not
|
||
normally the directory in which you started <b>find</b>. As with -exec, the
|
||
{} should be quoted if find is being invoked from a shell. This a much
|
||
more secure method for invoking commands, as it avoids race conditions
|
||
during resolution of the paths to the matched files. As with the
|
||
<b>-exec</b> action, the `+’ form of <b>-execdir</b> will build a command line
|
||
to process more than one matched file, but any given invocation of
|
||
<i>command</i> will only list files that exist in the same subdirectory. If
|
||
you use this option, you must ensure that your <b>$PATH</b> environment
|
||
variable does not reference `.’; otherwise, an attacker can run any
|
||
commands they like by leaving an appropriately-named file in a
|
||
directory in which you will run <b>-execdir</b>. The same applies to having
|
||
entries in <b>$PATH</b> which are empty or which are not absolute directory
|
||
names. If any invocation with the `+’ form returns a non-zero value as
|
||
exit status, then <b>find</b> returns a non-zero exit status. If <b>find</b>
|
||
encounters an error, this can sometimes cause an immediate exit, so
|
||
some pending commands may not be run at all. The result of the action
|
||
depends on whether the <b>+</b> or the <b>;</b> variant is being used; <b>-execdir
|
||
<i>command</i> {} +</b> always returns true, while <b>-execdir <i>command</i> {} ;</b>
|
||
returns true only if <i>command</i> returns 0.</dd>
|
||
|
||
<dt>-fls file</dt><dd>True; like <b>-ls</b> but write to <i>file</i> like <b>-fprint</b>. The
|
||
output file is always created, even if the predicate is never matched.
|
||
See the <b>UNUSUAL FILENAMES</b> section for information about how unusual
|
||
characters in filenames are handled.</dd>
|
||
|
||
<dt>-fprint file</dt><dd>True; print the full file name into file <i>file</i>. If
|
||
<i>file</i> does not exist when <b>find</b> is run, it is created; if it does
|
||
exist, it is truncated. The file names <i>/dev/stdout</i> and <i>/dev/stderr</i>
|
||
are handled specially; they refer to the standard output and standard
|
||
error output, respectively. The output file is always created, even if
|
||
the predicate is never matched. See the <b>UNUSUAL FILENAMES</b> section
|
||
for information about how unusual characters in filenames are handled.</dd>
|
||
|
||
<dt>-fprint0 file</dt><dd>True; like <b>-print0</b> but write to <i>file</i> like
|
||
<b>-fprint</b>. The output file is always created, even if the predicate is
|
||
never matched. See the <b>UNUSUAL FILENAMES</b> section for information
|
||
about how unusual characters in filenames are handled.</dd>
|
||
|
||
<dt>-fprintf file format</dt><dd>True; like <b>-printf</b> but write to <i>file</i> like
|
||
<b>-fprint</b>. The output file is always created, even if the predicate is
|
||
never matched. See the <b>UNUSUAL FILENAMES</b> section for information
|
||
about how unusual characters in filenames are handled.</dd>
|
||
|
||
<dt>-ls</dt><dd>True; list current file in <b>ls -dils</b> format on standard
|
||
output. The block counts are of 1 KB blocks, unless the environment
|
||
variable POSIXLY_CORRECT is set, in which case 512-byte blocks are
|
||
used. See the <b>UNUSUAL FILENAMES</b> section for information about how
|
||
unusual characters in filenames are handled.</dd>
|
||
|
||
<dt>-ok command ;</dt><dd><p>
|
||
Like <b>-exec</b> but ask the user first. If the user
|
||
agrees, run the command. Otherwise just return false. If the command
|
||
is run, its standard input is redirected from <i>/dev/null</i>.
|
||
</p>
|
||
|
||
<p>
|
||
The response to the prompt is matched against a pair of regular
|
||
expressions to determine if it is an affirmative or negative response.
|
||
This regular expression is obtained from the system if the
|
||
`POSIXLY_CORRECT’ environment variable is set, or otherwise from
|
||
<b>find</b>’s message translations. If the system has no suitable
|
||
definition, <b>find</b>’s own definition will be used. In either case, the
|
||
interpretation of the regular expression itself will be affected by
|
||
the environment variables ’LC_CTYPE’ (character classes) and
|
||
’LC_COLLATE’ (character ranges and equivalence classes).
|
||
</p></dd>
|
||
|
||
<dt>-okdir command ;</dt><dd>Like <b>-execdir</b> but ask the user first in the same
|
||
way as for <b>-ok</b>. If the user does not agree, just return false. If
|
||
the command is run, its standard input is redirected from <i>/dev/null</i>.</dd>
|
||
|
||
<dt>-print</dt><dd>True; print the full file name on the standard output,
|
||
followed by a newline. If you are piping the output of <b>find</b> into
|
||
another program and there is the faintest possibility that the files
|
||
which you are searching for might contain a newline, then you should
|
||
seriously consider using the <b>-print0</b> option instead of <b>-print</b>. See
|
||
the <b>UNUSUAL FILENAMES</b> section for information about how unusual
|
||
characters in filenames are handled.</dd>
|
||
|
||
<dt>-print0</dt><dd>True; print the full file name on the standard output,
|
||
followed by a null character (instead of the newline character that
|
||
<b>-print</b> uses). This allows file names that contain newlines or other
|
||
types of white space to be correctly interpreted by programs that
|
||
process the <b>find</b> output. This option corresponds to the <b>-0</b> option
|
||
of <b>xargs</b>.</dd>
|
||
|
||
<dt>-printf format</dt><dd><p>
|
||
True; print <i>format</i> on the standard output,
|
||
interpreting `\’ escapes and `%’ directives. Field widths and
|
||
precisions can be specified as with the *printf*(3) C function. Please
|
||
note that many of the fields are printed as %s rather than %d, and
|
||
this may mean that flags don’t work as you might expect. This also
|
||
means that the `-’ flag does work (it forces fields to be
|
||
left-aligned). Unlike <b>-print</b>, <b>-printf</b> does not add a newline at
|
||
the end of the string. The escapes and directives are:
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>\a</dt><dd>Alarm bell.</dd>
|
||
|
||
<dt>\b</dt><dd>Backspace.</dd>
|
||
|
||
<dt>\c</dt><dd>Stop printing from this format immediately and flush the
|
||
output.</dd>
|
||
|
||
<dt>\f</dt><dd>Form feed.</dd>
|
||
|
||
<dt>\n</dt><dd>Newline.</dd>
|
||
|
||
<dt>\r</dt><dd>Carriage return.</dd>
|
||
|
||
<dt>\t</dt><dd>Horizontal tab.</dd>
|
||
|
||
<dt>\v</dt><dd>Vertical tab.</dd>
|
||
|
||
<dt>\0</dt><dd>ASCII NUL.</dd>
|
||
|
||
<dt>\\</dt><dd>A literal backslash (`\’).</dd>
|
||
|
||
<dt>\NNN</dt><dd>The character whose ASCII code is NNN (octal).</dd>
|
||
</dl>
|
||
|
||
<p>
|
||
A `\’ character followed by any other character is treated as an
|
||
ordinary character, so they both are printed.
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>%%</dt><dd>A literal percent sign.</dd>
|
||
|
||
<dt>%a</dt><dd>File’s last access time in the format returned by the C
|
||
*ctime*(3) function.</dd>
|
||
|
||
<dt>%Ak</dt><dd><p>
|
||
File’s last access time in the format specified by <i>k</i>, which
|
||
is either `@’ or a directive for the C *strftime*(3) function. The
|
||
following shows an incomplete list of possible values for <i>k</i>.
|
||
Please refer to the documentation of *strftime*(3) for the full
|
||
list. Some of the conversion specification characters might not be
|
||
available on all systems, due to differences in the implementation
|
||
of the *strftime*(3) library function.
|
||
</p>
|
||
|
||
<ol class="org-ol">
|
||
<li>seconds since Jan. 1, 1970, 00:00 GMT, with fractional part.</li>
|
||
</ol>
|
||
|
||
<p>
|
||
Time fields:
|
||
</p>
|
||
|
||
<ol class="org-ol">
|
||
<li>hour (00..23)</li>
|
||
|
||
<li>hour (01..12)</li>
|
||
|
||
<li>hour ( 0..23)</li>
|
||
|
||
<li>hour ( 1..12)</li>
|
||
|
||
<li>minute (00..59)</li>
|
||
|
||
<li>locale’s AM or PM</li>
|
||
|
||
<li>time, 12-hour (hh:mm:ss [AP]M)</li>
|
||
|
||
<li>Second (00.00 .. 61.00). There is a fractional part.</li>
|
||
|
||
<li>time, 24-hour (hh:mm:ss.xxxxxxxxxx)</li>
|
||
|
||
<li>Date and time, separated by `+’, for example
|
||
`2004-04-28+22:22:05.0’. This is a GNU extension. The time is
|
||
given in the current timezone (which may be affected by setting
|
||
the TZ environment variable). The seconds field includes a
|
||
fractional part.</li>
|
||
|
||
<li>locale’s time representation (H:M:S). The seconds field includes
|
||
a fractional part.</li>
|
||
|
||
<li>time zone (e.g., EDT), or nothing if no time zone is
|
||
determinable</li>
|
||
</ol>
|
||
|
||
<p>
|
||
Date fields:
|
||
</p>
|
||
|
||
<ol class="org-ol">
|
||
<li>locale’s abbreviated weekday name (Sun..Sat)</li>
|
||
|
||
<li>locale’s full weekday name, variable length (Sunday..Saturday)</li>
|
||
|
||
<li>locale’s abbreviated month name (Jan..Dec)</li>
|
||
|
||
<li>locale’s full month name, variable length (January..December)</li>
|
||
|
||
<li>locale’s date and time (Sat Nov 04 12:02:33 EST 1989). The format
|
||
is the same as for *ctime*(3) and so to preserve compatibility
|
||
with that format, there is no fractional part in the seconds
|
||
field.</li>
|
||
|
||
<li>day of month (01..31)</li>
|
||
|
||
<li>date (mm/dd/yy)</li>
|
||
|
||
<li>date (yyyy-mm-dd)</li>
|
||
|
||
<li>same as b</li>
|
||
|
||
<li>day of year (001..366)</li>
|
||
|
||
<li>month (01..12)</li>
|
||
|
||
<li>week number of year with Sunday as first day of week (00..53)</li>
|
||
|
||
<li>day of week (0..6)</li>
|
||
|
||
<li>week number of year with Monday as first day of week (00..53)</li>
|
||
|
||
<li>locale’s date representation (mm/dd/yy)</li>
|
||
|
||
<li>last two digits of year (00..99)</li>
|
||
|
||
<li>year (1970…)</li>
|
||
</ol></dd>
|
||
|
||
<dt>%b</dt><dd>The amount of disk space used for this file in 512-byte
|
||
blocks. Since disk space is allocated in multiples of the filesystem
|
||
block size this is usually greater than %s/512, but it can also be
|
||
smaller if the file is a sparse file.</dd>
|
||
|
||
<dt>%c</dt><dd>File’s last status change time in the format returned by the C
|
||
*ctime*(3) function.</dd>
|
||
|
||
<dt>%Ck</dt><dd>File’s last status change time in the format specified by
|
||
<i>k</i>, which is the same as for %A.</dd>
|
||
|
||
<dt>%d</dt><dd>File’s depth in the directory tree; 0 means the file is a
|
||
starting-point.</dd>
|
||
|
||
<dt>%D</dt><dd>The device number on which the file exists (the st_dev field
|
||
of struct stat), in decimal.</dd>
|
||
|
||
<dt>%f</dt><dd>Print the basename; the file’s name with any leading
|
||
directories removed (only the last element). For <b>/</b>, the result is
|
||
`/’. See the <b>EXAMPLES</b> section for an example.</dd>
|
||
|
||
<dt>%F</dt><dd>Type of the filesystem the file is on; this value can be used
|
||
for -fstype.</dd>
|
||
|
||
<dt>%g</dt><dd>File’s group name, or numeric group ID if the group has no
|
||
name.</dd>
|
||
|
||
<dt>%G</dt><dd>File’s numeric group ID.</dd>
|
||
|
||
<dt>%h</dt><dd>Dirname; the Leading directories of the file’s name (all but
|
||
the last element). If the file name contains no slashes (since it is
|
||
in the current directory) the %h specifier expands to `.’. For files
|
||
which are themselves directories and contain a slash (including
|
||
<b>/</b>), %h expands to the empty string. See the <b>EXAMPLES</b> section for
|
||
an example.</dd>
|
||
|
||
<dt>%H</dt><dd>Starting-point under which file was found.</dd>
|
||
|
||
<dt>%i</dt><dd>File’s inode number (in decimal).</dd>
|
||
|
||
<dt>%k</dt><dd>The amount of disk space used for this file in 1 KB blocks.
|
||
Since disk space is allocated in multiples of the filesystem block
|
||
size this is usually greater than %s/1024, but it can also be
|
||
smaller if the file is a sparse file.</dd>
|
||
|
||
<dt>%l</dt><dd>Object of symbolic link (empty string if file is not a
|
||
symbolic link).</dd>
|
||
|
||
<dt>%m</dt><dd>File’s permission bits (in octal). This option uses the
|
||
`traditional’ numbers which most Unix implementations use, but if
|
||
your particular implementation uses an unusual ordering of octal
|
||
permissions bits, you will see a difference between the actual value
|
||
of the file’s mode and the output of %m. Normally you will want to
|
||
have a leading zero on this number, and to do this, you should use
|
||
the <b>#</b> flag (as in, for example, `%#m’).</dd>
|
||
|
||
<dt>%M</dt><dd>File’s permissions (in symbolic form, as for <b>ls</b>). This
|
||
directive is supported in findutils 4.2.5 and later.</dd>
|
||
|
||
<dt>%n</dt><dd>Number of hard links to file.</dd>
|
||
|
||
<dt>%p</dt><dd>File’s name.</dd>
|
||
|
||
<dt>%P</dt><dd>File’s name with the name of the starting-point under which it
|
||
was found removed.</dd>
|
||
|
||
<dt>%s</dt><dd>File’s size in bytes.</dd>
|
||
|
||
<dt>%S</dt><dd>File’s sparseness. This is calculated as (BLOCKSIZE*st_blocks
|
||
/ st_size). The exact value you will get for an ordinary file of a
|
||
certain length is system-dependent. However, normally sparse files
|
||
will have values less than 1.0, and files which use indirect blocks
|
||
may have a value which is greater than 1.0. In general the number of
|
||
blocks used by a file is file system dependent. The value used for
|
||
BLOCKSIZE is system-dependent, but is usually 512 bytes. If the file
|
||
size is zero, the value printed is undefined. On systems which lack
|
||
support for st_blocks, a file’s sparseness is assumed to be 1.0.</dd>
|
||
|
||
<dt>%t</dt><dd>File’s last modification time in the format returned by the C
|
||
*ctime*(3) function.</dd>
|
||
|
||
<dt>%Tk</dt><dd>File’s last modification time in the format specified by <i>k</i>,
|
||
which is the same as for %A.</dd>
|
||
|
||
<dt>%u</dt><dd>File’s user name, or numeric user ID if the user has no name.</dd>
|
||
|
||
<dt>%U</dt><dd>File’s numeric user ID.</dd>
|
||
|
||
<dt>%y</dt><dd>File’s type (like in <b>ls -l</b>), U=unknown type (shouldn’t
|
||
happen)</dd>
|
||
|
||
<dt>%Y</dt><dd>File’s type (like %y), plus follow symbolic links: `L’=loop,
|
||
`N’=nonexistent, `?’ for any other error when determining the type
|
||
of the target of a symbolic link.</dd>
|
||
|
||
<dt>%Z</dt><dd>(SELinux only) file’s security context.</dd>
|
||
|
||
<dt>%{ %[ %(</dt><dd>Reserved for future use.</dd>
|
||
</dl>
|
||
|
||
<p>
|
||
A `%’ character followed by any other character is discarded, but the
|
||
other character is printed (don’t rely on this, as further format
|
||
characters may be introduced). A `%’ at the end of the format argument
|
||
causes undefined behaviour since there is no following character. In
|
||
some locales, it may hide your door keys, while in others it may
|
||
remove the final page from the novel you are reading.
|
||
</p>
|
||
|
||
<p>
|
||
The %m and %d directives support the <b>#</b>, <b>0</b> and <b>+</b> flags, but the
|
||
other directives do not, even if they print numbers. Numeric
|
||
directives that do not support these flags include <b>G</b>, <b>U</b>, <b>b</b>, <b>D</b>,
|
||
<b>k</b> and <b>n</b>. The `-’ format flag is supported and changes the
|
||
alignment of a field from right-justified (which is the default) to
|
||
left-justified.
|
||
</p>
|
||
|
||
<p>
|
||
See the <b>UNUSUAL FILENAMES</b> section for information about how unusual
|
||
characters in filenames are handled.
|
||
</p></dd>
|
||
|
||
<dt>-prune</dt><dd>True; if the file is a directory, do not descend into it. If
|
||
<b>-depth</b> is given, then <b>-prune</b> has no effect. Because <b>-delete</b>
|
||
implies <b>-depth</b>, you cannot usefully use <b>-prune</b> and <b>-delete</b>
|
||
together. For example, to skip the directory <i>src/emacs</i> and all files
|
||
and directories under it, and print the names of the other files
|
||
found, do something like this:</dd>
|
||
</dl>
|
||
|
||
<pre class="example" id="org299e760">
|
||
find . -path ./src/emacs -prune -o -print
|
||
</pre>
|
||
|
||
<dl class="org-dl">
|
||
<dt>-quit</dt><dd>Exit immediately (with return value zero if no errors have
|
||
occurred). This is different to <b>-prune</b> because <b>-prune</b> only applies
|
||
to the contents of pruned directories, while <b>-quit</b> simply makes
|
||
<b>find</b> stop immediately. No child processes will be left running. Any
|
||
command lines which have been built by <b>-exec … +</b> or <b>-execdir …
|
||
+</b> are invoked before the program is exited. After <b>-quit</b> is
|
||
executed, no more files specified on the command line will be
|
||
processed. For example, `*find <i>/tmp/foo</i> <i>/tmp/bar</i> -print -quit*`
|
||
will print only `/tmp/foo`.<br />
|
||
One common use of <b>-quit</b> is to stop searching the file system once we
|
||
have found what we want. For example, if we want to find just a single
|
||
file we can do this:</dd>
|
||
</dl>
|
||
|
||
<pre class="example" id="orgd09d70a">
|
||
find / -name needle -print -quit
|
||
</pre>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org5523b97" class="outline-3">
|
||
<h3 id="org5523b97">OPERATORS</h3>
|
||
<div class="outline-text-3" id="text-org5523b97">
|
||
<p>
|
||
Listed in order of decreasing precedence:
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>( expr )</dt><dd>Force precedence. Since parentheses are special to the
|
||
shell, you will normally need to quote them. Many of the examples in
|
||
this manual page use backslashes for this purpose: `\(...\)’ instead
|
||
of `(…)’.</dd>
|
||
|
||
<dt>! expr</dt><dd>True if <i>expr</i> is false. This character will also usually
|
||
need protection from interpretation by the shell.</dd>
|
||
|
||
<dt>-not expr</dt><dd>Same as ! <i>expr</i>, but not POSIX compliant.</dd>
|
||
|
||
<dt>expr1 expr2</dt><dd>Two expressions in a row are taken to be joined with an
|
||
implied <b>-a</b>; <i>expr2</i> is not evaluated if <i>expr1</i> is false.</dd>
|
||
|
||
<dt>expr1 -a expr2</dt><dd>Same as <i>expr1 expr2</i>.</dd>
|
||
|
||
<dt>expr1 -and expr2</dt><dd>Same as <i>expr1 expr2</i>, but not POSIX compliant.</dd>
|
||
|
||
<dt>expr1 -o expr2</dt><dd>Or; <i>expr2</i> is not evaluated if <i>expr1</i> is true.</dd>
|
||
|
||
<dt>expr1 -or expr2</dt><dd>Same as <i>expr1</i> <b>-o</b> <i>expr2</i>, but not POSIX
|
||
compliant.</dd>
|
||
|
||
<dt>expr1 , expr2</dt><dd>List; both <i>expr1</i> and <i>expr2</i> are always evaluated.
|
||
The value of <i>expr1</i> is discarded; the value of the list is the value
|
||
of <i>expr2</i>. The comma operator can be useful for searching for several
|
||
different types of thing, but traversing the filesystem hierarchy only
|
||
once. The <b>-fprintf</b> action can be used to list the various matched
|
||
items into several different output files.</dd>
|
||
</dl>
|
||
|
||
<p>
|
||
Please note that <b>-a</b> when specified implicitly (for example by two
|
||
tests appearing without an explicit operator between them) or explicitly
|
||
has higher precedence than <b>-o</b>. This means that <b>find . -name afile -o
|
||
-name bfile -print</b> will never print <i>afile</i>.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org21a7342" class="outline-2">
|
||
<h2 id="org21a7342">UNUSUAL FILENAMES</h2>
|
||
<div class="outline-text-2" id="text-org21a7342">
|
||
<p>
|
||
Many of the actions of <b>find</b> result in the printing of data which is
|
||
under the control of other users. This includes file names, sizes,
|
||
modification times and so forth. File names are a potential problem
|
||
since they can contain any character except `\0’ and `/’. Unusual
|
||
characters in file names can do unexpected and often undesirable things
|
||
to your terminal (for example, changing the settings of your function
|
||
keys on some terminals). Unusual characters are handled differently by
|
||
various actions, as described below.
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>-print0, -fprint0</dt><dd>Always print the exact filename, unchanged, even
|
||
if the output is going to a terminal.</dd>
|
||
|
||
<dt>-ls, -fls</dt><dd>Unusual characters are always escaped. White space,
|
||
backslash, and double quote characters are printed using C-style
|
||
escaping (for example `\f’, `\“’). Other unusual characters are
|
||
printed using an octal escape. Other printable characters (for <b>-ls</b>
|
||
and <b>-fls</b> these are the characters between octal 041 and 0176) are
|
||
printed as-is.</dd>
|
||
|
||
<dt>-printf, -fprintf</dt><dd>If the output is not going to a terminal, it is
|
||
printed as-is. Otherwise, the result depends on which directive is in
|
||
use. The directives %D, %F, %g, %G, %H, %Y, and %y expand to values
|
||
which are not under control of files’ owners, and so are printed
|
||
as-is. The directives %a, %b, %c, %d, %i, %k, %m, %M, %n, %s, %t, %u
|
||
and %U have values which are under the control of files’ owners but
|
||
which cannot be used to send arbitrary data to the terminal, and so
|
||
these are printed as-is. The directives %f, %h, %l, %p and %P are
|
||
quoted. This quoting is performed in the same way as for GNU <b>ls</b>.
|
||
This is not the same quoting mechanism as the one used for <b>-ls</b> and
|
||
<b>-fls</b>. If you are able to decide what format to use for the output of
|
||
<b>find</b> then it is normally better to use `\0’ as a terminator than to
|
||
use newline, as file names can contain white space and newline
|
||
characters. The setting of the `LC_CTYPE’ environment variable is used
|
||
to determine which characters need to be quoted.</dd>
|
||
|
||
<dt>-print, -fprint</dt><dd>Quoting is handled in the same way as for <b>-printf</b>
|
||
and <b>-fprintf</b>. If you are using <b>find</b> in a script or in a situation
|
||
where the matched files might have arbitrary names, you should
|
||
consider using <b>-print0</b> instead of <b>-print</b>.</dd>
|
||
</dl>
|
||
|
||
<p>
|
||
The <b>-ok</b> and <b>-okdir</b> actions print the current filename as-is. This
|
||
may change in a future release.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-orgfe44b9c" class="outline-2">
|
||
<h2 id="orgfe44b9c">STANDARDS CONFORMANCE</h2>
|
||
<div class="outline-text-2" id="text-orgfe44b9c">
|
||
<p>
|
||
For closest compliance to the POSIX standard, you should set the
|
||
POSIXLY_CORRECT environment variable. The following options are
|
||
specified in the POSIX standard (IEEE Std 1003.1-2008, 2016 Edition):
|
||
</p>
|
||
|
||
<dl class="org-dl">
|
||
<dt>-H</dt><dd>This option is supported.</dd>
|
||
|
||
<dt>-L</dt><dd>This option is supported.</dd>
|
||
|
||
<dt>-name</dt><dd>This option is supported, but POSIX conformance depends on
|
||
the POSIX conformance of the system’s <b>fnmatch*(3) library function.
|
||
As of findutils-4.2.2, shell metacharacters (`</b>’, `?’ or `[]’ for
|
||
example) match a leading `.’, because IEEE PASC interpretation 126
|
||
requires this. This is a change from previous versions of findutils.</dd>
|
||
|
||
<dt>-type</dt><dd>Supported. POSIX specifies `b’, `c’, `d’, `l’, `p’, `f’ and
|
||
`s’. GNU find also supports `D’, representing a Door, where the OS
|
||
provides these. Furthermore, GNU find allows multiple types to be
|
||
specified at once in a comma-separated list.</dd>
|
||
|
||
<dt>-ok</dt><dd>Supported. Interpretation of the response is according to the
|
||
`yes’ and `no’ patterns selected by setting the `LC_MESSAGES’
|
||
environment variable. When the `POSIXLY_CORRECT’ environment variable
|
||
is set, these patterns are taken system’s definition of a positive
|
||
(yes) or negative (no) response. See the system’s documentation for
|
||
*nl_langinfo*(3), in particular YESEXPR and NOEXPR. When
|
||
`POSIXLY_CORRECT’ is not set, the patterns are instead taken from
|
||
<b>find</b>’s own message catalogue.</dd>
|
||
|
||
<dt>-newer</dt><dd>Supported. If the file specified is a symbolic link, it is
|
||
always dereferenced. This is a change from previous behaviour, which
|
||
used to take the relevant time from the symbolic link; see the HISTORY
|
||
section below.</dd>
|
||
|
||
<dt>-perm</dt><dd>Supported. If the POSIXLY_CORRECT environment variable is not
|
||
set, some mode arguments (for example +a+x) which are not valid in
|
||
POSIX are supported for backward-compatibility.</dd>
|
||
|
||
<dt>Other primaries</dt><dd>The primaries <b>-atime</b>, <b>-ctime</b>, <b>-depth</b>,
|
||
<b>-exec</b>, <b>-group</b>, <b>-links</b>, <b>-mtime</b>, <b>-nogroup</b>, <b>-nouser</b>, <b>-ok</b>,
|
||
<b>-path</b>, <b>-print</b>, <b>-prune</b>, <b>-size</b>, <b>-user</b> and <b>-xdev</b> are all
|
||
supported.</dd>
|
||
</dl>
|
||
|
||
<p>
|
||
The POSIX standard specifies parentheses `(’, `)’, negation `!’ and the
|
||
logical AND/OR operators <b>-a</b> and <b>-o</b>.
|
||
</p>
|
||
|
||
<p>
|
||
All other options, predicates, expressions and so forth are extensions
|
||
beyond the POSIX standard. Many of these extensions are not unique to
|
||
GNU find, however.
|
||
</p>
|
||
|
||
<p>
|
||
The POSIX standard requires that <b>find</b> detects loops:
|
||
</p>
|
||
|
||
<blockquote>
|
||
<p>
|
||
The <b>find</b> utility shall detect infinite loops; that is, entering a
|
||
previously visited directory that is an ancestor of the last file
|
||
encountered. When it detects an infinite loop, find shall write a
|
||
diagnostic message to standard error and shall either recover its
|
||
position in the hierarchy or terminate.
|
||
</p>
|
||
</blockquote>
|
||
|
||
<p>
|
||
GNU <b>find</b> complies with these requirements. The link count of
|
||
directories which contain entries which are hard links to an ancestor
|
||
will often be lower than they otherwise should be. This can mean that
|
||
GNU find will sometimes optimise away the visiting of a subdirectory
|
||
which is actually a link to an ancestor. Since <b>find</b> does not actually
|
||
enter such a subdirectory, it is allowed to avoid emitting a diagnostic
|
||
message. Although this behaviour may be somewhat confusing, it is
|
||
unlikely that anybody actually depends on this behaviour. If the leaf
|
||
optimisation has been turned off with <b>-noleaf</b>, the directory entry
|
||
will always be examined and the diagnostic message will be issued where
|
||
it is appropriate. Symbolic links cannot be used to create filesystem
|
||
cycles as such, but if the <b>-L</b> option or the <b>-follow</b> option is in
|
||
use, a diagnostic message is issued when <b>find</b> encounters a loop of
|
||
symbolic links. As with loops containing hard links, the leaf
|
||
optimisation will often mean that <b>find</b> knows that it doesn’t need to
|
||
call <i>stat()</i> or <i>chdir()</i> on the symbolic link, so this diagnostic is
|
||
frequently not necessary.
|
||
</p>
|
||
|
||
<p>
|
||
The <b>-d</b> option is supported for compatibility with various BSD systems,
|
||
but you should use the POSIX-compliant option <b>-depth</b> instead.
|
||
</p>
|
||
|
||
<p>
|
||
The POSIXLY_CORRECT environment variable does not affect the behaviour
|
||
of the <b>-regex</b> or <b>-iregex</b> tests because those tests aren’t specified
|
||
in the POSIX standard.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org64c6aa7" class="outline-2">
|
||
<h2 id="org64c6aa7">ENVIRONMENT VARIABLES</h2>
|
||
<div class="outline-text-2" id="text-org64c6aa7">
|
||
<dl class="org-dl">
|
||
<dt>LANG</dt><dd>Provides a default value for the internationalization
|
||
variables that are unset or null.</dd>
|
||
|
||
<dt>LC_ALL</dt><dd>If set to a non-empty string value, override the values of
|
||
all the other internationalization variables.</dd>
|
||
|
||
<dt>LC_COLLATE</dt><dd>The POSIX standard specifies that this variable affects
|
||
the pattern matching to be used for the <b>-name</b> option. GNU find uses
|
||
the *fnmatch*(3) library function, and so support for `LC_COLLATE’
|
||
depends on the system library. This variable also affects the
|
||
interpretation of the response to <b>-ok</b>; while the `LC_MESSAGES’
|
||
variable selects the actual pattern used to interpret the response to
|
||
<b>-ok</b>, the interpretation of any bracket expressions in the pattern
|
||
will be affected by `LC_COLLATE’.</dd>
|
||
|
||
<dt>LC_CTYPE</dt><dd>This variable affects the treatment of character classes
|
||
used in regular expressions and also with the <b>-name</b> test, if the
|
||
system’s *fnmatch*(3) library function supports this. This variable
|
||
also affects the interpretation of any character classes in the
|
||
regular expressions used to interpret the response to the prompt
|
||
issued by <b>-ok</b>. The `LC_CTYPE’ environment variable will also affect
|
||
which characters are considered to be unprintable when filenames are
|
||
printed; see the section UNUSUAL FILENAMES.</dd>
|
||
|
||
<dt>LC_MESSAGES</dt><dd>Determines the locale to be used for internationalised
|
||
messages. If the `POSIXLY_CORRECT’ environment variable is set, this
|
||
also determines the interpretation of the response to the prompt made
|
||
by the <b>-ok</b> action.</dd>
|
||
|
||
<dt>NLSPATH</dt><dd>Determines the location of the internationalisation message
|
||
catalogues.</dd>
|
||
|
||
<dt>PATH</dt><dd>Affects the directories which are searched to find the
|
||
executables invoked by <b>-exec</b>, <b>-execdir</b>, <b>-ok</b> and <b>-okdir</b>.</dd>
|
||
|
||
<dt>POSIXLY_CORRECT</dt><dd><p>
|
||
Determines the block size used by <b>-ls</b> and <b>-fls</b>.
|
||
If <b>POSIXLY_CORRECT</b> is set, blocks are units of 512 bytes. Otherwise
|
||
they are units of 1024 bytes.
|
||
</p>
|
||
|
||
<p>
|
||
Setting this variable also turns off warning messages (that is,
|
||
implies <b>-nowarn</b>) by default, because POSIX requires that apart from
|
||
the output for <b>-ok</b>, all messages printed on stderr are diagnostics
|
||
and must result in a non-zero exit status.
|
||
</p>
|
||
|
||
<p>
|
||
When POSIXLY_CORRECT is not set, <b>-perm <i>+zzz</i></b> is treated just like
|
||
<b>-perm <i>/zzz</i></b> if <i>+zzz</i> is not a valid symbolic mode. When
|
||
POSIXLY_CORRECT is set, such constructs are treated as an error.
|
||
</p>
|
||
|
||
<p>
|
||
When POSIXLY_CORRECT is set, the response to the prompt made by the
|
||
<b>-ok</b> action is interpreted according to the system’s message
|
||
catalogue, as opposed to according to <b>find</b>’s own message
|
||
translations.
|
||
</p></dd>
|
||
|
||
<dt>TZ</dt><dd>Affects the time zone used for some of the time-related format
|
||
directives of <b>-printf</b> and <b>-fprintf</b>.</dd>
|
||
</dl>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-orgd4763a7" class="outline-2">
|
||
<h2 id="orgd4763a7">EXAMPLES</h2>
|
||
<div class="outline-text-2" id="text-orgd4763a7">
|
||
</div>
|
||
<div id="outline-container-org0307417" class="outline-3">
|
||
<h3 id="org0307417">Simple `find|xargs` approach</h3>
|
||
<div class="outline-text-3" id="text-org0307417">
|
||
<ul class="org-ul">
|
||
<li>Find files named <i>core</i> in or below the directory <i>/tmp</i> and delete
|
||
them.</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="org7fc1249">
|
||
$ find /tmp -name core -type f -print | xargs /bin/rm -f
|
||
</pre>
|
||
|
||
<p>
|
||
Note that this will work incorrectly if there are any filenames
|
||
containing newlines, single or double quotes, or spaces.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org29219f8" class="outline-3">
|
||
<h3 id="org29219f8">Safer `find -print0 | xargs -0` approach</h3>
|
||
<div class="outline-text-3" id="text-org29219f8">
|
||
<ul class="org-ul">
|
||
<li>Find files named <i>core</i> in or below the directory <i>/tmp</i> and delete
|
||
them, processing filenames in such a way that file or directory names
|
||
containing single or double quotes, spaces or newlines are correctly
|
||
handled.</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="orgd10f61e">
|
||
$ find /tmp -name core -type f -print0 | xargs -0 /bin/rm -f
|
||
</pre>
|
||
|
||
<p>
|
||
The <b>-name</b> test comes before the <b>-type</b> test in order to avoid having
|
||
to call <b>stat(2)</b> on every file.
|
||
</p>
|
||
|
||
<p>
|
||
Note that there is still a race between the time <b>find</b> traverses the
|
||
hierarchy printing the matching filenames, and the time the process
|
||
executed by <b>xargs</b> works with that file.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org4ed62ec" class="outline-3">
|
||
<h3 id="org4ed62ec">Executing a command for each file</h3>
|
||
<div class="outline-text-3" id="text-org4ed62ec">
|
||
<ul class="org-ul">
|
||
<li>Run <i>file</i> on every file in or below the current directory.</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="org917b7b0">
|
||
$ find . -type f -exec file '{}' \;
|
||
</pre>
|
||
|
||
<p>
|
||
Notice that the braces are enclosed in single quote marks to protect
|
||
them from interpretation as shell script punctuation. The semicolon is
|
||
similarly protected by the use of a backslash, though single quotes
|
||
could have been used in that case also.
|
||
</p>
|
||
|
||
<p>
|
||
In many cases, one might prefer the <b>`-exec … +`</b> or better the
|
||
<b>`-execdir … +`</b> syntax for performance and security reasons.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org9f299cf" class="outline-3">
|
||
<h3 id="org9f299cf">Traversing the filesystem just once - for 2 different actions</h3>
|
||
<div class="outline-text-3" id="text-org9f299cf">
|
||
<ul class="org-ul">
|
||
<li>Traverse the filesystem just once, listing set-user-ID files and
|
||
directories into <i>/root/suid.txt</i> and large files into
|
||
<i>/root/big.txt</i>.</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="org28088e9">
|
||
$ find / \
|
||
\( -perm -4000 -fprintf /root/suid.txt '%#m %u %p\n' \) , \
|
||
|
||
|
||
\( -size +100M -fprintf /root/big.txt '%-10s %p\n' \)
|
||
</pre>
|
||
|
||
<p>
|
||
This example uses the line-continuation character ’\’ on the first two
|
||
lines to instruct the shell to continue reading the command on the next
|
||
line.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-orgf6fd0a8" class="outline-3">
|
||
<h3 id="orgf6fd0a8">Searching files by age</h3>
|
||
<div class="outline-text-3" id="text-orgf6fd0a8">
|
||
<ul class="org-ul">
|
||
<li>Search for files in your home directory which have been modified in
|
||
the last twenty-four hours.</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="orgd83dbca">
|
||
$ find $HOME -mtime 0
|
||
</pre>
|
||
|
||
<p>
|
||
This command works this way because the time since each file was last
|
||
modified is divided by 24 hours and any remainder is discarded. That
|
||
means that to match <b>-mtime</b> <b>0</b>, a file will have to have a
|
||
modification in the past which is less than 24 hours ago.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org31063bf" class="outline-3">
|
||
<h3 id="org31063bf">Searching files by permissions</h3>
|
||
<div class="outline-text-3" id="text-org31063bf">
|
||
<ul class="org-ul">
|
||
<li>Search for files which are executable but not readable.</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="org4cb1995">
|
||
$ find /sbin /usr/sbin -executable \! -readable -print
|
||
</pre>
|
||
|
||
<ul class="org-ul">
|
||
<li>Search for files which have read and write permission for their owner,
|
||
and group, but which other users can read but not write to.</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="org1a929d2">
|
||
$ find . -perm 664
|
||
</pre>
|
||
|
||
<p>
|
||
Files which meet these criteria but have other permissions bits set (for
|
||
example if someone can execute the file) will not be matched.
|
||
</p>
|
||
|
||
<ul class="org-ul">
|
||
<li>Search for files which have read and write permission for their owner
|
||
and group, and which other users can read, without regard to the
|
||
presence of any extra permission bits (for example the executable
|
||
bit).</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="orgfd417b4">
|
||
$ find . -perm -664
|
||
</pre>
|
||
|
||
<p>
|
||
This will match a file which has mode <i>0777</i>, for example.
|
||
</p>
|
||
|
||
<ul class="org-ul">
|
||
<li>Search for files which are writable by somebody (their owner, or their
|
||
group, or anybody else).</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="orgf2049a7">
|
||
$ find . -perm /222
|
||
</pre>
|
||
|
||
<ul class="org-ul">
|
||
<li>Search for files which are writable by either their owner or their
|
||
group.</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="orgc4827c7">
|
||
$ find . -perm /220
|
||
$ find . -perm /u+w,g+w
|
||
$ find . -perm /u=w,g=w
|
||
</pre>
|
||
|
||
<p>
|
||
All three of these commands do the same thing, but the first one uses
|
||
the octal representation of the file mode, and the other two use the
|
||
symbolic form. The files don’t have to be writable by both the owner and
|
||
group to be matched; either will do.
|
||
</p>
|
||
|
||
<ul class="org-ul">
|
||
<li>Search for files which are writable by both their owner and their
|
||
group.</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="org1c37e1f">
|
||
$ find . -perm -220
|
||
$ find . -perm -g+w,u+w
|
||
</pre>
|
||
|
||
<p>
|
||
Both these commands do the same thing.
|
||
</p>
|
||
|
||
<ul class="org-ul">
|
||
<li>A more elaborate search on permissions.</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="org1c60173">
|
||
$ find . -perm -444 -perm /222 \! -perm /111
|
||
$ find . -perm -a+r -perm /a+w \! -perm /a+x
|
||
</pre>
|
||
|
||
<p>
|
||
These two commands both search for files that are readable for everybody
|
||
(<b>-perm -444</b> or <b>-perm -a+r</b>), have at least one write bit set (<b>-perm
|
||
/222</b> or <b>-perm /a+w</b>) but are not executable for anybody (<b>! -perm
|
||
/111</b> or <b>! -perm /a+x</b> respectively).
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-orgb7c0ca9" class="outline-3">
|
||
<h3 id="orgb7c0ca9">Pruning - omitting files and subdirectories</h3>
|
||
<div class="outline-text-3" id="text-orgb7c0ca9">
|
||
<ul class="org-ul">
|
||
<li>Copy the contents of <i>/source-dir</i> to <i>/dest-dir</i>, but omit files and
|
||
directories named <i>.snapshot</i> (and anything in them). It also omits
|
||
files or directories whose name ends in <i>’~’</i>, but not their contents.</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="org563fc85">
|
||
$ cd /source-dir
|
||
$ find . -name .snapshot -prune -o \( \! -name '*~' -print0 \) \
|
||
|
||
|
||
| cpio -pmd0 /dest-dir
|
||
</pre>
|
||
|
||
<p>
|
||
The construct <b>-prune -o \( ... -print0 \)</b> is quite common. The idea
|
||
here is that the expression before <b>-prune</b> matches things which are to
|
||
be pruned. However, the <b>-prune</b> action itself returns true, so the
|
||
following <b>-o</b> ensures that the right hand side is evaluated only for
|
||
those directories which didn’t get pruned (the contents of the pruned
|
||
directories are not even visited, so their contents are irrelevant). The
|
||
expression on the right hand side of the <b>-o</b> is in parentheses only for
|
||
clarity. It emphasises that the <b>-print0</b> action takes place only for
|
||
things that didn’t have <b>-prune</b> applied to them. Because the default
|
||
`and’ condition between tests binds more tightly than <b>-o</b>, this is the
|
||
default anyway, but the parentheses help to show what is going on.
|
||
</p>
|
||
|
||
<ul class="org-ul">
|
||
<li>Given the following directory of projects and their associated SCM
|
||
administrative directories, perform an efficient search for the
|
||
projects’ roots:</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="orgb765b91">
|
||
$ find repo/ \
|
||
\( -exec test -d '{}/.svn' \; \
|
||
-or -exec test -d '{}/.git' \; \
|
||
-or -exec test -d '{}/CVS' \; \
|
||
\) -print -prune
|
||
</pre>
|
||
|
||
<p>
|
||
Sample output:
|
||
</p>
|
||
|
||
<pre class="example" id="orgd312189">
|
||
repo/project1/CVS
|
||
repo/gnu/project2/.svn
|
||
repo/gnu/project3/.svn
|
||
repo/gnu/project3/src/.svn
|
||
repo/project4/.git
|
||
</pre>
|
||
|
||
<p>
|
||
In this example, <b>-prune</b> prevents unnecessary descent into directories
|
||
that have already been discovered (for example we do not search
|
||
<i>project3/src</i> because we already found <i>project3</i>.svn/), but ensures
|
||
sibling directories (<i>project2</i> and <i>project3</i>) are found.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org177a409" class="outline-3">
|
||
<h3 id="org177a409">Other useful examples</h3>
|
||
<div class="outline-text-3" id="text-org177a409">
|
||
<ul class="org-ul">
|
||
<li>Search for several file types.</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="org427b22b">
|
||
$ find /tmp -type f,d,l
|
||
</pre>
|
||
|
||
<p>
|
||
Search for files, directories, and symbolic links in the directory
|
||
<i>/tmp</i> passing these types as a comma-separated list (GNU extension),
|
||
which is otherwise equivalent to the longer, yet more portable:
|
||
</p>
|
||
|
||
<pre class="example" id="orgafe6100">
|
||
$ find /tmp \( -type f -o -type d -o -type l \)
|
||
</pre>
|
||
|
||
<ul class="org-ul">
|
||
<li>Search for files with the particular name <i>needle</i> and stop
|
||
immediately when we find the first one.</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="orgbdffe3d">
|
||
$ find / -name needle -print -quit
|
||
</pre>
|
||
|
||
<ul class="org-ul">
|
||
<li>Demonstrate the interpretation of the <b>%f</b> and <b>%h</b> format directives
|
||
of the <b>-printf</b> action for some corner-cases. Here is an example
|
||
including some output.</li>
|
||
</ul>
|
||
|
||
<pre class="example" id="orge1cbeae">
|
||
$ find . .. / /tmp /tmp/TRACE compile compile/64/tests/find -maxdepth 0 -printf '[%h][%f]\n'
|
||
[.][.]
|
||
[.][..]
|
||
[][/]
|
||
[][tmp]
|
||
[/tmp][TRACE]
|
||
[.][compile]
|
||
[compile/64/tests][find]
|
||
</pre>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org00806f3" class="outline-2">
|
||
<h2 id="org00806f3">EXIT STATUS</h2>
|
||
<div class="outline-text-2" id="text-org00806f3">
|
||
<p>
|
||
<b>find</b> exits with status 0 if all files are processed successfully,
|
||
greater than 0 if errors occur. This is deliberately a very broad
|
||
description, but if the return value is non-zero, you should not rely on
|
||
the correctness of the results of <b>find</b>.
|
||
</p>
|
||
|
||
<p>
|
||
When some error occurs, <b>find</b> may stop immediately, without completing
|
||
all the actions specified. For example, some starting points may not
|
||
have been examined or some pending program invocations for <b>-exec … {}
|
||
+</b> or <b>“-execdir … {} +</b> may not have been performed.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-orgabb7b5a" class="outline-2">
|
||
<h2 id="orgabb7b5a">HISTORY</h2>
|
||
<div class="outline-text-2" id="text-orgabb7b5a">
|
||
<p>
|
||
As of findutils-4.2.2, shell metacharacters (`*’, `?’ or `[]’ for
|
||
example) used in filename patterns match a leading `.’, because IEEE
|
||
POSIX interpretation 126 requires this.
|
||
</p>
|
||
|
||
<p>
|
||
As of findutils-4.3.3, <b>-perm /000</b> now matches all files instead of
|
||
none.
|
||
</p>
|
||
|
||
<p>
|
||
Nanosecond-resolution timestamps were implemented in findutils-4.3.3.
|
||
</p>
|
||
|
||
<p>
|
||
As of findutils-4.3.11, the <b>-delete</b> action sets <b>find</b>’s exit status
|
||
to a nonzero value when it fails. However, <b>find</b> will not exit
|
||
immediately. Previously, <b>find</b>’s exit status was unaffected by the
|
||
failure of <b>-delete</b>.
|
||
</p>
|
||
|
||
<table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">
|
||
|
||
|
||
<colgroup>
|
||
<col class="org-left" />
|
||
|
||
<col class="org-right" />
|
||
|
||
<col class="org-left" />
|
||
</colgroup>
|
||
<tbody>
|
||
<tr>
|
||
<td class="org-left">Feature</td>
|
||
<td class="org-right">Added in</td>
|
||
<td class="org-left">Also occurs in</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-newerXY</td>
|
||
<td class="org-right">4.3.3</td>
|
||
<td class="org-left">BSD</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-D</td>
|
||
<td class="org-right">4.3.1</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-O</td>
|
||
<td class="org-right">4.3.1</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-readable</td>
|
||
<td class="org-right">4.3.0</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-writable</td>
|
||
<td class="org-right">4.3.0</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-executable</td>
|
||
<td class="org-right">4.3.0</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-regextype</td>
|
||
<td class="org-right">4.2.24</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-exec … +</td>
|
||
<td class="org-right">4.2.12</td>
|
||
<td class="org-left">POSIX</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-execdir</td>
|
||
<td class="org-right">4.2.12</td>
|
||
<td class="org-left">BSD</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-okdir</td>
|
||
<td class="org-right">4.2.12</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-samefile</td>
|
||
<td class="org-right">4.2.11</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-H</td>
|
||
<td class="org-right">4.2.5</td>
|
||
<td class="org-left">POSIX</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-L</td>
|
||
<td class="org-right">4.2.5</td>
|
||
<td class="org-left">POSIX</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-P</td>
|
||
<td class="org-right">4.2.5</td>
|
||
<td class="org-left">BSD</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-delete</td>
|
||
<td class="org-right">4.2.3</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-quit</td>
|
||
<td class="org-right">4.2.3</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-d</td>
|
||
<td class="org-right">4.2.3</td>
|
||
<td class="org-left">BSD</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-wholename</td>
|
||
<td class="org-right">4.2.0</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-iwholename</td>
|
||
<td class="org-right">4.2.0</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-ignore_readdir_race</td>
|
||
<td class="org-right">4.2.0</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-fls</td>
|
||
<td class="org-right">4.0</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-ilname</td>
|
||
<td class="org-right">3.8</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-iname</td>
|
||
<td class="org-right">3.8</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-ipath</td>
|
||
<td class="org-right">3.8</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td class="org-left">-iregex</td>
|
||
<td class="org-right">3.8</td>
|
||
<td class="org-left"> </td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<p>
|
||
The syntax .B -perm +MODE was removed in findutils-4.5.12, in favour of
|
||
.B -perm <b>/MODE</b>. The <b>+MODE</b> syntax had been deprecated since
|
||
findutils-4.2.21 which was released in 2005.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org276a566" class="outline-2">
|
||
<h2 id="org276a566">NON-BUGS</h2>
|
||
<div class="outline-text-2" id="text-org276a566">
|
||
</div>
|
||
<div id="outline-container-orgd2b2f71" class="outline-3">
|
||
<h3 id="orgd2b2f71">Operator precedence surprises</h3>
|
||
<div class="outline-text-3" id="text-orgd2b2f71">
|
||
<p>
|
||
The command <b>find . -name afile -o -name bfile -print</b> will never print
|
||
<i>afile</i> because this is actually equivalent to <b>find . -name afile -o \(
|
||
-name bfile -a -print \)</b>. Remember that the precedence of <b>-a</b> is
|
||
higher than that of <b>-o</b> and when there is no operator specified between
|
||
tests, <b>-a</b> is assumed.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-orga0a531c" class="outline-3">
|
||
<h3 id="orga0a531c">“paths must precede expression” error message</h3>
|
||
<div class="outline-text-3" id="text-orga0a531c">
|
||
<pre class="example" id="org421ca3a">
|
||
$ find . -name *.c -print
|
||
find: paths must precede expression
|
||
find: possible unquoted pattern after predicate `-name'?
|
||
</pre>
|
||
|
||
<p>
|
||
This happens when the shell could expand the pattern <i>*.c</i> to more than
|
||
one file name existing in the current directory, and passing the
|
||
resulting file names in the command line to <b>find</b> like this:
|
||
</p>
|
||
|
||
<pre class="example" id="org3ecd687">
|
||
find . -name frcode.c locate.c word_io.c -print
|
||
</pre>
|
||
|
||
<p>
|
||
That command is of course not going to work, because the <b>-name</b>
|
||
predicate allows exactly only one pattern as argument. Instead of doing
|
||
things this way, you should enclose the pattern in quotes or escape the
|
||
wildcard, thus allowing <b>find</b> to use the pattern with the wildcard
|
||
during the search for file name matching instead of file names expanded
|
||
by the parent shell:
|
||
</p>
|
||
|
||
<pre class="example" id="org4aa94cc">
|
||
$ find . -name '*.c' -print
|
||
$ find . -name \*.c -print
|
||
</pre>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org8a4cbb8" class="outline-2">
|
||
<h2 id="org8a4cbb8">BUGS</h2>
|
||
<div class="outline-text-2" id="text-org8a4cbb8">
|
||
<p>
|
||
There are security problems inherent in the behaviour that the POSIX
|
||
standard specifies for <b>find</b>, which therefore cannot be fixed. For
|
||
example, the <b>-exec</b> action is inherently insecure, and <b>-execdir</b>
|
||
should be used instead.
|
||
</p>
|
||
|
||
<p>
|
||
The environment variable <b>LC_COLLATE</b> has no effect on the <b>-ok</b> action.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-orga84f7d6" class="outline-2">
|
||
<h2 id="orga84f7d6">REPORTING BUGS</h2>
|
||
<div class="outline-text-2" id="text-orga84f7d6">
|
||
<p>
|
||
GNU findutils online help:
|
||
<a href="https://www.gnu.org/software/findutils/#get-help">https://www.gnu.org/software/findutils/#get-help</a><br />
|
||
Report any translation bugs to <a href="https://translationproject.org/team/">https://translationproject.org/team/</a>
|
||
</p>
|
||
|
||
<p>
|
||
Report any other issue via the form at the GNU Savannah bug tracker:
|
||
</p>
|
||
|
||
<blockquote>
|
||
<p>
|
||
<a href="https://savannah.gnu.org/bugs/?group=findutils">https://savannah.gnu.org/bugs/?group=findutils</a>
|
||
</p>
|
||
</blockquote>
|
||
|
||
<p>
|
||
General topics about the GNU findutils package are discussed at the
|
||
<i>bug-findutils</i> mailing list:
|
||
</p>
|
||
|
||
<blockquote>
|
||
<p>
|
||
<a href="https://lists.gnu.org/mailman/listinfo/bug-findutils">https://lists.gnu.org/mailman/listinfo/bug-findutils</a>
|
||
</p>
|
||
</blockquote>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-orgbae495c" class="outline-2">
|
||
<h2 id="orgbae495c">COPYRIGHT</h2>
|
||
<div class="outline-text-2" id="text-orgbae495c">
|
||
<p>
|
||
Copyright © 1990-2021 Free Software Foundation, Inc. License GPLv3+: GNU
|
||
GPL version 3 or later <a href="https://gnu.org/licenses/gpl.html">https://gnu.org/licenses/gpl.html</a>.<br />
|
||
This is free software: you are free to change and redistribute it. There
|
||
is NO WARRANTY, to the extent permitted by law.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-org1bcb8eb" class="outline-2">
|
||
<h2 id="org1bcb8eb">SEE ALSO</h2>
|
||
<div class="outline-text-2" id="text-org1bcb8eb">
|
||
<p>
|
||
*chmod*(1), *locate*(1), *ls*(1), *updatedb*(1), *xargs*(1), *lstat*(2),
|
||
*stat*(2), *ctime*(3) *fnmatch*(3), *printf*(3), *strftime*(3),
|
||
*locatedb*(5), *regex*(7)
|
||
</p>
|
||
|
||
<p>
|
||
Full documentation <a href="https://www.gnu.org/software/findutils/find">https://www.gnu.org/software/findutils/find</a><br />
|
||
or available locally via: <b>info find</b>
|
||
</p>
|
||
|
||
<div style="display: block; float:right;">
|
||
XXXXXX
|
||
<img src="logo.png"/>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div id="postamble" class="status">
|
||
<p class="author">Author: dt</p>
|
||
<p class="date">Created: 2021-12-23 Thu 19:44</p>
|
||
</div>
|
||
</body>
|
||
</html>
|