Connect commands

INPUT · Slides

Split the errors off (`2>`)

01 / 08

> cannot catch an error

Let us try something. ls a file that is not there, and point the result at a file with >.

ls missing.txt > out.txt

The error comes out on the screen anyway. And out.txt is empty.

That feels wrong, doesn't it? You pointed the way out at a file, so why is it on the screen?

Because errors come out of a different way out.

~ $ ls missing.txt > out.txtls: missing.txt: No such file or directory~ $ wc -c out.txt0 out.txt

02 / 08

The ways in and out are numbered

At the start of this chapter we said there are two ways out. Each of them has a number.

NumberNameWhat goes through it
0standard inputwhat comes in
1standard outputthe ordinary result
2standard errorthe errors

> is in fact short for 1>. So only number 1 was pointed at the file, and number 2 stayed on the screen.

When you want to point the errors, you write the number. That is 2>.

03 / 08

Why they are kept apart

It looks like a nuisance, but it is a very considerate arrangement.

When you are gathering results into a file with >, you do not want errors mixed in. A No such file line landing in the middle of the data you are adding up is no good to anyone.

Errors, on the other hand, want to be seen straight away. Buried in a file, you would never notice them.

So they are split into two from the start. Results to the file, trouble to the human — that is the arrangement out of the box.

04 / 08

2> splits the errors off

ls missing.txt 2> err.txt

Write that and the error goes into err.txt and nothing appears on the screen.

You can also send each of them to its own file.

ls names.txt missing.txt > out.txt 2> err.txt

What worked goes to out.txt, the error to err.txt. One command, and what succeeded and what failed are sorted apart.

~ $ ls names.txt missing.txt > out.txt 2> err.txt~ $ cat out.txtnames.txt~ $ cat err.txtls: missing.txt: No such file or directory

05 / 08

2>&1 puts them together

Sometimes you want the opposite: both of them in one file. For that you write 2>&1.

ls names.txt missing.txt > all.txt 2>&1

Read it as "send number 2 wherever number 1 is going". The & in &1 marks it as the way out numbered 1 (rather than a file called 1).

The order matters. Write > all.txt first and 2>&1 after. The other way round, number 1 is still the screen, so number 2 goes to the screen too.

06 / 08

/dev/null — the place things go to disappear

/dev/null is a special file where whatever you write vanishes. However much you write it never grows, and reading it gives you nothing.

Not a wastebasket — think of a bucket with no bottom. What you throw in does not come back.

ls names.txt missing.txt 2> /dev/null

That throws the errors away and shows you only what worked.

It earns its keep most with find. Search all over the place and you get a pile of "you are not allowed to look" errors mixed in, and 2> /dev/null hushes them.

07 / 08

Getting errors into a pipe

A pipe (|) also carries only number 1. So errors do not go through a pipe.

ls missing.txt | grep No        # nothing comes outls missing.txt 2>&1 | grep No   # it does

When you want to search error messages with grep, you need 2>&1. It is a handy shape to know, because it lets you count errors and pick particular ones out.

08 / 08

Now have a go

This lesson makes errors on purpose. You will be naming a file that does not exist, missing.txt, over and over.

An error message is made of three parts.

ls: missing.txt: No such file or directory^who   ^about what   ^what happened

Get into the habit of reading who is complaining first. Whether it says ls: or -sh: changes where you go to fix it.