|
Size: 13943
Comment: added "+" terminator to find -exec in actions
|
Size: 2049
Comment: http://quitheotsindi.55fast.com/canmore-alberta-canada-highland-games.html canmore alberta canada highland games http://iveryailyor.55fast.com/vestavia-hills-houses.html vestavia hills houses http:/
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #pragma section-numbers 2 = Using Find = [[TableOfContents]] {{{find(1)}}} is an extremely useful command for shell scripts, but it's very poorly understood. This is due in part to a complex syntax (perhaps the most complex of all the standard Unix commands that aren't actually programming languages like {{{awk}}}); and in part to poorly written man pages. (The GNU version's man page didn't even have examples until late 2006!) The very first thing you should do before you proceed any further is actually ''read'' your system's man page for the {{{find}}} command. You don't have to memorize it, or understand ''every'' part, but you should at least have looked at all the different parts of it once, so you have a general idea what's going on. Then, you might want to look at the [http://www.openbsd.org/cgi-bin/man.cgi?query=find&apropos=0&sektion=1&manpath=OpenBSD+Current&arch=i386&format=html OpenBSD man page] for comparison. Sometimes, you'll understand one man page more than another. Just realize that not all of the implementations are the same; the OpenBSD one may have features that yours lacks, and ''vice versa''. But many people find the BSD man pages easy to read, so it might help you with the concepts. Now, let's talk a bit about what {{{find}}} does, and when and how you should consider using it. == Overview == Here's the basic idea: {{{find}}} descends through a hierarchy of files, matches files that meet specified criteria, and then does stuff with them. This is really important, so I'm going to write it out again: * {{{find}}} descends through a hierarchy of files, * matches files that meet specified criteria, and then * does stuff with them. Let's give a few quick examples, to illustrate its basic operations. First up: {{{find . . ./bar ./bar/foo.jpg ./foo.mp3 ./apple.txt}}} If you don't specify the {{{.}}} for current directory, some version of find will assume that's what you want; others may generate an error. You should always specify which directory you want {{{find}}} to descend into. If you don't specify any criteria for which files should be matched, {{{find}}} will match ''every'' file (including directories, symlinks, block and character devices, FIFOs, sockets -- you name it). We didn't add any such flags on our first example, so we got every file and directory. Finally, if you don't specify an action to be performed on each matched file, most modern versions of {{{find}}} will assume you want to print their names, to standard output, with a newline after each one. (Some extremely old versions of {{{find}}} may do nothing -- it's really best to specify the action.) If we want to be explicit, we would write it thus: {{{find . -print }}} This would produce the same output we saw earlier; I won't repeat it. You might also have observed that the output of {{{find}}} is not necessarily sorted into alphabetical order like that of {{{ls(1)}}}. It simply gives you the files in the order in which they appear within a directory. == Searching based on names == Now, let's apply a filtering option. Suppose we only want to find files ending with {{{.jpg}}}: {{{find . -name '*.jpg' -print ./bar/foo.jpg}}} In this case, only one file matched our criteria, so we only got one line of output. If we ''also'' wanted to find all the files ending with {{{.mp3}}}: {{{find . \( -name '*.mp3' -o -name '*.jpg' \) -print ./bar/foo.jpg ./foo.mp3}}} That's a little more complex than we've shown so far, so let's go over it in detail. The central part is this: {{{-name '*.mp3' -o -name '*.jpg' }}} This simply says "we want files that meet this ''or'' that". The {{{-o}}} is a logical "or" operator, and is the most portable way to write it. (Some other versions of {{{find}}} support {{{-or}}} as well, but why use a non-portable flag that's more typing, when there's a portable one already?) We enclosed the whole "or" expression in parentheses, because we want it to be treated as a single unit, especially when we start chaining it together with other expressions (as we'll do shortly). The parentheses themselves have to be passed to {{{find}}} intact, so we had to protect them with backslashes, because the parentheses ''also'' have a special meaning to the shell. We could have used quotes instead of backslashes, as well. Finally, we applied the explicit {{{-print}}} action. Any files that meet our criteria will have their names printed. If you want a file to meet multiple criteria, you can specify multiple flags. There's an implicit logical "and" any time you put two filters together without the {{{-o}}} in between them: {{{find . -name '*.mp3' -name '*.jpg' -print }}} This one produces no output, because we asked for all the files that end with {{{.mp3}}} ''and'' end with {{{.jpg}}}. Clearly, no file can satisfy both criteria, so we got nothing. Now, let's chain together an "or" and an implicit "and", as we promised earlier: {{{find . \( -name '*.mp3' -o -name '*.jpg' \) -name 'foo*' -print ./bar/foo.jpg ./foo.mp3}}} Here, we have our same "or" expression as before: the file must have a name ending with {{{.mp3}}} ''or'' {{{.jpg}}}. In addition, it must have a name beginning with {{{foo}}}. The results are shown. Notice that {{{-name}}} matches only the file's name inside of the deepest directory -- in our example, {{{foo.jpg}}} and not {{{bar/foo.jpg}}} or {{{./bar/foo.jpg}}}. That's why the {{{-name 'foo*'}}} filter is able to match it. If we want to look at the directory names, we must use the {{{-path}}} filter instead: {{{find . -path 'bar*' -print }}} That produces no output. Why? Look here: {{{find . -path './bar*' -print ./bar ./bar/foo.jpg}}} {{{-path}}} looks at the ''entire'' pathname (what will be a line of {{{find}}}'s output if {{{-print}}} is used) in order to match things. This includes the leading {{{./}}} in our case. We can also negate an expression: {{{griffon:/tmp/greg$ find . ! -path '*bar*' -print . ./foo.mp3 ./apple.txt}}} The {{{!}}} negates the expression which follows it, so we got every file that does ''not'' have {{{bar}}} somewhere in its full pathname. == Searching based on times == One of the most common uses of {{{find}}} in system maintenance scripts is to find all the files that are older than ''something'', either a relative instant of time such as "30 days ago", or some other file. If we want to find all the files older than 30 days (for example, to clean up a temporary directory), we use: {{{find /tmp -mtime +30 -print }}} The {{{-mtime}}} flag is one of the three filters used to inspect a file's timestamps. A file on a Unix file system has three timestamps: ''modification time'' (mtime), ''access time'' (atime), and ''change time'' (ctime). There is nothing that stores a file's creation time. Let me say that again for those who aren't paying attention: '''''It is totally impossible to know when a file was created.''''' That information is not stored anywhere. In our example, we used {{{-mtime}}}, which looks at a file's modification time. This is the timestamp we see when we run {{{ls -l}}}, and is the most commonly used. It's updated any time the contents of a file are changed by writing to it. We could also have used {{{-atime}}} to look at a file's access time -- this can be see with {{{ls -lu}}}, and is updated whenever the contents of the file are read (unless the system administrator has explicitly turned off atime updates on this file system). It's quite rare to use ctime (change time), which is updated any time a file's metadata (permissions, ownership, etc.) are changed (e.g., by {{{chmod}}}). The {{{+30}}} means we want all the files that are ''more than'' 30 days old. If we had used this: {{{find . -mtime 30 -print }}} We would've gotten all the files that are exactly 30 days old (when rounded to the nearest day -- see the manual for the exact definitions). That's not often useful. However, if we wanted all the files that have been modified ''within'' the last 30 days, we would use: {{{find . -mtime -30 -print }}} This gives us all the files whose modification time is ''less than'' 30 days ago. The other common use for matching files based on their times is when we want to find all the files that have been modified since the last time we checked. That logic looks like this: {{{find /etc -newer /var/log/backup.timestamp -print touch /var/log/backup.timestamp}}} This is the basic structure for doing an incremental system backup: find all the files that have changed since the last backup, and then update our timestamp file for the next run. (Clearly we'd have to something more than just {{{-print}}} the files, in order to have a meaningful backup, but we'll look at actions in the next section.) == Actions == A more complete example for cleaning up /tmp might look something like this: {{{find . -type f -mtime +30 -exec rm -f {} \; }}} Here, we've got a few new things. First of all, we used {{{-type f}}} to specify that we only want to match ordinary files -- not directories, and not sockets, and so on. Then, we have our {{{-mtime +30}}} filter. As we've already seen, two filters adjacent to each other like this have an implicit "and" between them, so the file must match both criteria to be considered. Now, our action is no longer {{{-print}}}, because we don't want to see them. Instead, we've got this: {{{-exec rm -f {} \; }}} The {{{-exec}}} is an action flag, which says "we want to execute a command"; the command follows it, and is terminated by a semicolon ({{{;}}}). Now, the semicolon is also a special character for the shell, so we have to protect it with a backslash, just as we did for the parentheses earlier. And once again, we could have used quotes around it instead; the backslash is one character less, so it's the traditional preference. The curly brace pair in our command is a special argument to {{{find}}}. Each time a command is executed by {{{-exec}}} for a file that's been matched, the {} is replaced with the file's name. So, supposing we matched three files under {{{/tmp}}}, {{{find}}} might execute the following commands: {{{rm -f /tmp/foo285712 rm -f /tmp/core rm -f /tmp/haha naughty file; "rm -rf ."}}} Even if some user attempts to subvert the system by putting a Trojan horse in the filename as in this example, the {} replacement is perfectly safe. The commands that {{{find}}} executes are not passed to a shell. There is no word splitting, and no parsing of the filename. The filename is merely passed as an argument to the command (in our case, {{{rm}}}) directly. Nothing in the filename will matter at all. When you terminate the {{{-exec}}} with a {{{+}}} instead of the {{{\;}}}, then {{{find}}} will run the command with as many filenames as arguments as possible, not just one by one. Not all versions of {{{find}}} support this. == xargs == The use of {{{xargs}}} is generally not recommended, because of its inherent problems. However, people ''do'' use it, and you ''will'' need to understand it when you see it. {{{xargs}}} is a standard Unix command that reads words from standard input, and then uses each word as the argument to an arbitrary command. It processes the words in big chunks (although you can specify how many words to process at a time), so that the command is called relatively few times. For example, {{{find . -name '*.temp' -print | xargs rm # Don't actually do this! }}} In this example (which by the way is '''very''' bad), the {{{find}}} commands generates a list of filenames matching our filter, and writes them to standard output, with a newline after each one. {{{xargs}}} reads these names, one word at a time, and then constructs one or more big {{{rm}}} commands, to delete the files. Rather than calling {{{rm}}} once per file, this will only call it a few times at most; this can be a dramatic savings in time on systems where {{{fork()}}} is really slow. However, it has a serious problem: a file with spaces in its name will be read as multiple words, and then {{{rm}}} will attempt to remove each individual word, rather than the single multiple-word file that we actually wanted. Because of this serious issue (but because people still wanted the efficiency of only forking {{{rm}}} once), a few different workarounds have been created. The first involves a change to both {{{find}}} and {{{xargs}}}: {{{find . -name '*.temp' -print0 | xargs -0 rm }}} With the {{{-print0}}} action, instead of putting a newline after each filename, {{{find}}} uses a NUL character (ASCII 00) instead. Since NUL is the only character which is ''not'' valid in a Unix pathname, it's the only possible delimiter between pathnames in a data stream. The corresponding {{{-0}}} (that's "dash zero", not "dash oh") flag to {{{xargs}}} tells {{{xargs}}}, instead of reading whitespace-separated words, to read NUL-delimited words instead. This feature is typically found on GNU and BSD systems. The second workaround is more commonly found on POSIX systems (and some ''extremely'' recent GNU systems), and involves abandoning xargs altogether: {{{find . -name '*.temp' -exec rm {} + }}} The {{{+}}} (instead of {{{;}}}) at the end of the {{{-exec}}} action tells {{{find}}} to use an internal {{{xargs}}}-like feature which causes the {{{rm}}} command to be invoked only once for every chunk of files, instead of once per file. Unfortunately, with the POSIX-style {{{+}}} feature, the {} must appear at the ''end'' of the command. This does not work: {{{find . -type f -exec cp {} ../bar + # Generates an error. }}} Would've been nice, wouldn't it? Oh well. == -prune == To be written. And then burned, most likely. |
http://quitheotsindi.55fast.com/canmore-alberta-canada-highland-games.html canmore alberta canada highland games http://iveryailyor.55fast.com/vestavia-hills-houses.html vestavia hills houses http://iveryailyor.55fast.com/mika-from-my-friends-hot-mom.html mika from my friends hot mom http://iveryailyor.55fast.com/steps-to-do-hair-styles.html steps to do hair styles http://iveryailyor.55fast.com/index.html origami holiday decorations easy http://quitheotsindi.55fast.com/church-of-the-most-holy-trinity.html church of the most holy trinity http://quitheotsindi.55fast.com/information-warfare---a-fundamental-paradigm-of-infowar.html information warfare - a fundamental paradigm of infowar http://quitheotsindi.55fast.com/holy-name-hospital-teaneck.html holy name hospital teaneck http://quitheotsindi.55fast.com/lindane-insecticide.html lindane insecticide http://quitheotsindi.55fast.com/best-all-inclusive-vacation-packages.html best all inclusive vacation packages http://iveryailyor.55fast.com/holiday-inn-orlando-fl.html holiday inn orlando fl http://iveryailyor.55fast.com/what-can-i-do-to-keep-dog-hair-off-bottom-of-wood-furniture.html what can i do to keep dog hair off bottom of wood furniture http://quitheotsindi.55fast.com/cherokee-indians-in-alleghany-north-carolina.html cherokee indians in alleghany north carolina http://iveryailyor.55fast.com/calgary-highland-games.html calgary highland games http://quitheotsindi.55fast.com/south-hills-pet-resort-reviews.html south hills pet resort reviews http://iveryailyor.55fast.com/walmart-hair-stylists.html walmart hair stylists http://quitheotsindi.55fast.com/girls-makin-out-in-shower.html girls makin out in shower http://iveryailyor.55fast.com/the-banning-of-ddt-as-an-insecticide-in-the-us.html the banning of ddt as an insecticide in the us. http://iveryailyor.55fast.com/holiday--decorations-and-whitely-county-indiana.html holiday decorations and whitely county, indiana http://quitheotsindi.55fast.com/my-sisters-hot-friend-3.html my sisters hot friend 3 |
http://quitheotsindi.55fast.com/canmore-alberta-canada-highland-games.html canmore alberta canada highland games http://iveryailyor.55fast.com/vestavia-hills-houses.html vestavia hills houses http://iveryailyor.55fast.com/mika-from-my-friends-hot-mom.html mika from my friends hot mom http://iveryailyor.55fast.com/steps-to-do-hair-styles.html steps to do hair styles http://iveryailyor.55fast.com/index.html origami holiday decorations easy http://quitheotsindi.55fast.com/church-of-the-most-holy-trinity.html church of the most holy trinity http://quitheotsindi.55fast.com/information-warfare---a-fundamental-paradigm-of-infowar.html information warfare - a fundamental paradigm of infowar http://quitheotsindi.55fast.com/holy-name-hospital-teaneck.html holy name hospital teaneck http://quitheotsindi.55fast.com/lindane-insecticide.html lindane insecticide http://quitheotsindi.55fast.com/best-all-inclusive-vacation-packages.html best all inclusive vacation packages http://iveryailyor.55fast.com/holiday-inn-orlando-fl.html holiday inn orlando fl http://iveryailyor.55fast.com/what-can-i-do-to-keep-dog-hair-off-bottom-of-wood-furniture.html what can i do to keep dog hair off bottom of wood furniture http://quitheotsindi.55fast.com/cherokee-indians-in-alleghany-north-carolina.html cherokee indians in alleghany north carolina http://iveryailyor.55fast.com/calgary-highland-games.html calgary highland games http://quitheotsindi.55fast.com/south-hills-pet-resort-reviews.html south hills pet resort reviews http://iveryailyor.55fast.com/walmart-hair-stylists.html walmart hair stylists http://quitheotsindi.55fast.com/girls-makin-out-in-shower.html girls makin out in shower http://iveryailyor.55fast.com/the-banning-of-ddt-as-an-insecticide-in-the-us.html the banning of ddt as an insecticide in the us. http://iveryailyor.55fast.com/holiday--decorations-and-whitely-county-indiana.html holiday decorations and whitely county, indiana http://quitheotsindi.55fast.com/my-sisters-hot-friend-3.html my sisters hot friend 3