Keep the result in a file (`>`)

01 / 07

A command has ways out and a way in

This chapter is all about joining things up, and for that you want one picture in your head first.

Every command has two ways out and one way in.

standard output — where the ordinary result comes out
standard error — where only the errors come out
standard input — where it takes text in

Usually both ways out are wired to the screen, so you cannot see any difference between them. What this chapter teaches is rewiring them to somewhere else.

02 / 07

`>` points the output at a file

Write a > and the standard output goes to a file instead of the screen.

ls > list.txt

Type that and nothing comes out on the screen, because the result went into the file.

Think of > as an arrow saying "pour it over here". The result of the command on the left flows into the file on the right.

~ $ ls > list.txt~ $ cat list.txtlist.txtmemo.txtnames.txtnumbers.txtresults

03 / 07

The file gets made for you

The file on the right of > gets made if it is not there. No need to touch it first.

And if it is there, its contents get wiped. That is the frightening part.

echo A > memo.txt   # memo.txt now holds nothing but A

No confirmation, no warning. It overwrites in silence. That attitude runs through all the Unix tools: whoever typed it is assumed to know what they are doing.

04 / 07

You can keep any output at all

> works on any command. You are only rewiring the way out, and the command itself never finds out.

ls > list.txtsort numbers.txt > sorted.txtwc -l names.txt > counted.txtfind . -name '*.txt' > found.txt

This "the same trick works on every tool" is what makes the command line pleasant. There is nothing extra to learn.

05 / 07

Never point it at the same file

There is one shape you must never write.

sort numbers.txt > numbers.txt    # the contents disappear

It looks like it should read as it writes, but the shell empties the file first and only then runs the command. By the time sort goes to read, there is nothing left.

The result is a 0 byte file. This one catches people out, so let us have you see it with your own eyes (there is a question on it later).

06 / 07

You can write it at the front instead

In fact the > does not have to come after the command.

> out.txt ls        # this works tools > out.txt        # this is how you normally write it

Same meaning. > is an instruction to the shell, not an argument to the command, so it can go anywhere.

You would normally put it at the end, but keep the fact in mind — it is proof that the command is not the one receiving the >. ls has no idea it is writing to a file.

07 / 07

Now have a go

names.txt holds three names, numbers.txt holds three numbers, and memo.txt holds a one line note. There is an empty box called results too.

Get into the habit of checking with cat after you write something out. When your way of working puts nothing on the screen, checking is the only way to know it worked.