next up previous contents index
Next: Actions Up: findthe file searcher Previous: Options


The first two tests are very simple to understand: -false always return false, while -true always return true. Other tests which do not need the specification of a value are -empty, which returns true whether the file is empty, and the couple -nouser / -nogroup, which return true in the case that no entry in /etc/passwd or /etc/group match the user/group id of the file owner. This is a common thing which happens in a multiuser system; a user is deleted, but files owned by her remain in the strangest part of the filesystems, and due to Murphy's laws take a lot of space.

Of course, it is possible to search for a specific user or group. The tests are -uid nn and -gid nn. Unfortunately it is not possibile to give directly the user name, but it is necessary to use the numeric id, nn.

allowed to use the forms +nn, which means ``a value strictly greater than nn'', and -nn, which means ``a value strictly less than nn''. This is rather silly in the case of UIDs, but it will turn handy with other tests.

Another useful option is -type c, which returns true if the file is of type c. The mnemonics for the possible choices are the same found in ls; so we have b when the file is a block special; c when the file is character special; d for directories; p for named pipes; l for symbolic links, and s for sockets. Regular files are indicated with f. A related test is -xtype, which is similar to -type except in the case of symbolic links. If -follow has not been given, the file pointed at is checked, instead of the link itself. Completely unrelated is the test -fstype type. In this case, the filesystem type is checked. I think that the information is got from file /etc/mtab, the one stating the mounting filesystems; I am certain that types nfs, tmp, msdos and ext2 are recognized.

Tests -inum nn and -links nn check whether the file has inode number nn, or nn links, while -size nn is true if the file has nn 512-bytes blocks allocated. (well, not precisely: for sparse files unallocated blocks are counted too). As nowadays the result of ls -s is not always measured in 512-bytes chunks (Linux for example uses 1k as the unit), it is possible to append to nn the character b, which means to count in butes, or k, to count in kilobytes.

Permission bits are checked through the test -perm mode. If mode has no leading sign, then the permission bits of the file must exactly match them. A leading - means that all permission bits must be set, but makes no assumption for the other; a leading + is satisfied just if any of the bits are set. Oops! I forgot saying that the mode is written in octal or symbolically, like you use them in chmod.

Next group of tests is related to the time in which a file has been last used. This comes handy when a user has filled his space, as usually there are many files he did not use since ages, and whose meaning he has forgot. The trouble is to locate them, and find is the only hope in sight. -atime nn is true if the file was last accessed nn days ago, -ctime nn if the file status was last changed nn days ago - for example, with a chmod - and -mtime nn if the file was last modified nn days ago. Sometimes you need a more precise timestamp; the test -newer file is satisfied if the file considered has been modified later than file. So, you just have to use touch with the desidered date, and you're done. GNU find add the tests -anewer and -cnewer which behave similarly; and the tests -amin, -cmin and -mmin which count time in minutes instead than 24-hours periods.

Last but not the least, the test I use more often. -name pattern is true if the file name exactly matches pattern, which is more or less the one you would use in a standard ls. Why `more or less'? Because of course you have to remember that all the parameters are processed by the shell, and those lovely metacharacters are expanded. So, a test like -name foo* won't return what you want, and you should either write -name foo\* or -name "foo*". This is probably one of the most common mistakes made by careless users, so write it in BIG letters on your screen. Another problem is that, like with ls, leading dots are not recognized. To cope with this, you can use test -path pattern which does not worry about dot and slashes when comparing the path of the considered file with pattern.

next up previous contents index
Next: Actions Up: findthe file searcher Previous: Options

Converted on:
Mon Apr 1 08:59:56 EST 1996