For example, the program wc (for word count) reads text from its input stream and produces as its output stream three numbers indicating the number of lines, words, and characters that it saw. You could invoke this directly:

in which case, you would see as output: For this to be very useful, however, we need to make it accept a file as input. This is done by using the < operator in the shell. Think of the < as an arrow indicating data flowing towards the command from a filename: If hello.c is this file: then the command produces the output

On the output end, the shell operator > redirects the standard output into a file (again, think of this as an arrow indicating data flowing into a filename from the command):

produces no output on the screen, but creates a file called hello.wc. That file will contain the output of the wc command.

The output redirection operator has a couple of important variants. First, the shell generally does not allow you to redirect into an existing file. If you give the command

a second time, the shell will refuse to perform the command. You can force the shell to delete an existing file and create a new one for redirection by changing the > to >!.

Second, sometimes we would like to add output to the end of an existing file instead of replacing that file. This is done with the operator >>. So the code sequence

would result in a file hello.wc with contents regardless of whether hello.wc had existed previously.

To pipe the output of one command into the input of another, use the shell operator |. A common example of a pipe is to take a command that may have a large amount of output and to pipe it through more to facilitate viewing.

As you gain facility with a greater variety of Unix text manipulation commands, you will find that redirection and pipes can be a powerful combination. For example, suppose that you have written program myprog that emits a great deal of output, among which might be some error messages starting with the phrase “ERROR:” . If you wanted to read only the error messages, you could, of course, just view all the output, watching for the occasional error message:

But if the program produces a lot of output, this will quickly become tedious. However, we previously encountered the program grep, which scans its input stream, printing only those lines matching a given regular expression. By piping the myprog output through grep, we can limit the output to the part we really want to see:

xargs reads a list of file names from the standard input and fills those file names in to a command of your choosing. In its simplest form, you can use xargs like this:

In this form xargs will read a list of file names (paths) from the standard input and will simply tack them on to the end of the partial command.

Where do the file names come from? You're not likely to type them directly at the keyboard. (If you were going to do that, you would probably just have typed the whole command.) So, usually, you will run this with a list of files names that you have collected into a text file, or you may pipe into xargs the output of a command that lists the files you want.

You can control the maximum number of files that xargs will pack into one command using the -n flag.

The most common reason for doing this is because not all Unix commands work on arbitrarily long lists of files. Some work only on a single file, making -n 1 a useful option.

In this basic form, xargs tacks the file names onto the end of the generated command. But sometimes you might want the filenames placed into the middle of the command. The -i option permits that. If xargsis executed with a -i flag, then it looks in your partial command for the characters “{}” and places your files there (one at a time, as if you had said “-n 1” .

As an example of using xargs, suppose that you have a directory with a large number of data files. You want to copy those files into a new directory. However, you have edited many of these files, so the original directory is littered with backup files left by the editors. You would prefer not to copy those backups. The backups can be recognized because some end in “.bak” and some end in “~” .

Now, normally, you would copy files from one directory to another like this:

But there is not obvious way to rewrite the wildcard pattern * to exclude the backup files (wildards are great for including things, not so great for excluding them).

But a list of file names is nothing more than text, and we have some powerful tools like grep for editing and selecting text.

Wildcards give us a useway to describe a number of files at once. But wildcards have a limitation. They can only describe one "level" of directories at a time. You can write a wildcard expression to look at a variety of files in one directory, or at a variety of files in one or more subdirectories of that directory, or in one or more sub-subdirectories of that one. But you cannot write a wildcard expression that will simultaneously describe files in a directory and in its subdirectories.

Some commands will try to help with this. Both cp and rm, for example, offer a -r flag ( “r” for “recursive” ) that will descend into an arbitrary number of levels of subdirectories, but these are all-or-nothing selections. You can't be very selective about what files get processed this way.

This is where find come in. find is the Swiss army knife of Unix commands. It provides all kinds of ways to select files, no matter how deep they are in your directory structure. It provides a variety of things it can do with selected files, or it can fill their names into an arbitrary command in a manner similar to xargs -i.

The general form of a find command is

find looks at each file and directory given in the list. For directories, it also looks at all files and directories inside those, descending as far as it can from directory to directory.

The actions in the command are all given a flags (beginning with “-” ). Some actions will “do something” to a file. Others are used to select which files will be passed on to the later commands in the list.

The most common selection action is -name, which is given a wildcard expression to match file names against.

Other useful ways to select files include -type, which chooses different "types" of files. Directories are type 'd' and ordinary files are type 'f'.

You can also select files based on how long ago they were modified.

What can find do to files it selects? The simplest possibility if to simply print the file name, which is done by the action “-print” . In fact, that's the behavior we have seen in all the examples so far, because it's the default if you don't do anything else to the selected files. Sometimes, though, you use -print because you wnat to print a file name and do something else to a file.

You can get a bit more information than just the name:

The most powerful use of find comes form the -exec action, which allows you to specify an arbitrary Unix command that you want applied to selected files. The command is terminated by a quoted semi-colon ( “\;” ) and should contain the characters “{}” at the point where you want to insert the file name.

Closely related is -ok, which asks for permission before applying a command.

Actually, because many commands, such as grep, can be used to test files for certain properties, -exec can actually be used to select files as well as to operate on them.

There are many other possible actions as well. See the man page for details.