time

time - a hands-on Linux lab on a real virtual machine.

Put a stopwatch on any command with time. The three lines (real, user, sys) and what each means, timing a whole pipeline, and the external /usr/bin/time -v. time is shape-only: your seconds vary run to run, so the drills teach the three labels and the moves, not the digits.

You have started to string commands together. Soon you will write ones that copy thousands of files, crunch a big log, or sleep on purpose. And a question shows up the moment a command feels slow: how long did that actually take?

Guessing is no good. Staring at the screen and counting in your head is worse. There is a command whose entire job is to answer this, exactly, to the millisecond. You put it in front of any command you run, and when that command finishes, it tells you how long it took. It is called time.

The black boxes in this lesson are a practice terminal: a safe sandbox that only checks the one command each step teaches, so you cannot break anything. time measures REAL durations, so the exact seconds it prints change from machine to machine and run to run. The numbers shown here are one real capture, kept as an example. What never changes is the SHAPE of the answer, and that shape is the whole lesson.

time measures how long another command takes to run. You do not run time on its own. You put the word time in front of a command, press Enter, and time steps aside so that command runs normally. The one thing time adds is this: when the command finishes, time prints how long it took.

Think of it as a stopwatch you clip onto any command. It starts the watch when the command starts, stops it when the command ends, and reads the time out loud. The command itself behaves exactly as it always would. time just watches from the side and reports.

In bash, time is not a separate program you can lose. It is built into the shell itself, a builtin. That is why time is always there the moment you open a terminal, and why it can measure a whole pipeline, not just a single program. Hold on to the word builtin; it explains a lot later in this lesson.

The cleanest way to see time work is to time something whose length you already know. sleep 1 is a command that does nothing at all for one second, then exits. It is the perfect stopwatch test, because you know the answer before you run it: about one second.

Before you run the next block, commit to an expectation out loud: the number time reports should land right around one second, because that is how long sleep 1 waits. Now run it and watch for three new lines that appear AFTER the one-second pause:

time sleep 1

prompt: student@linuxcamp:~$ answer: time sleep 1 output:

real 0m1.003s user 0m0.001s sys 0m0.002s hint: Type the word time, a space, then the command you want to measure: time sleep 1

Those exact seconds belong to the run this was captured on. On YOUR machine the numbers after the decimal point will differ every single time. That is expected, because time measures a real, live duration. What stays identical everywhere is the three labels down the left side, real, user, and sys, and that real lands near one second for sleep 1. The labels are the lesson, not the digits.

Every time you run time, you get the same three labelled lines. Learn them once and you can read the timing of any command:

The line your eye should jump to first is real. That is the honest, human answer to how long did this take. In the sleep 1 capture, real reads about one second because the command spent its whole life just waiting.

Here is the giveaway that a command was mostly WAITING, not working: real is large while user and sys are tiny. sleep 1 waited a whole second, so real is near 1s, but it asked the CPU to do almost nothing, so user and sys are near zero. A command that is genuinely crunching numbers instead shows a big user. Reading the gap between real and user tells you whether a slow command is stuck waiting or actually busy.

Because time is a shell builtin, it does not just measure one program. It measures whatever the whole line does, including a pipeline where you chain commands with the | symbol so one command's output feeds the next.

Time a small pipeline: generate the numbers 1 through 100000, then count them. You do not need to know these two commands in depth here. seq prints a run of numbers and wc -l counts lines. What matters is that time wraps the ENTIRE line and reports one timing for the lot:

time seq 100000 | wc -l

prompt: student@linuxcamp:~$ answer: time seq 100000 | wc -l output: 100000

real 0m0.012s user 0m0.008s sys 0m0.006s hint: Put time in front of the whole pipeline, pipe and all: time seq 100000 | wc -l

Two things print here, in order. First the pipeline's own output, 100000, the line count. Then the three timing lines from time. Your seconds will be different and probably very small, because counting numbers is fast work. Notice the contrast with sleep 1: here user and sys are close to real, because this pipeline was actually BUSY on the CPU, not waiting. Same three labels, a completely different story in the numbers.

There are actually two time tools on most Linux machines, and the difference trips people up, so meet both now.

The one you have been using is the builtin, part of bash itself. There is also an external time, a separate program that lives at /usr/bin/time. It does the same core job but can report far more when you ask, like the peak memory a command used. You reach the external one by typing its full path. Its verbose form is /usr/bin/time -v:

/usr/bin/time -v sleep 1

prompt: student@linuxcamp:~$ answer: /usr/bin/time -v sleep 1 output: Command being timed: "sleep 1" User time (seconds): 0.00 System time (seconds): 0.00 Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.00 Maximum resident set size (kbytes): 1792 hint: Type the full path, then -v, then the command: /usr/bin/time -v sleep 1

Two honest cautions. First, your numbers here will differ, same as before, and the Maximum resident set size (peak memory) figure especially depends on the machine. Second, the external /usr/bin/time is NOT installed on every system by default. If it is missing, the command above fails with an error instead of a report. That specific error is coming up next, so you know it on sight.

time has a small set of failure messages, and each one points at a clear cause. Learn to read them and you will never be stuck wondering what went wrong.

bash: /usr/bin/time: No such file or directory You asked for the EXTERNAL time by its full path, but that program is not installed on this machine. It means only the external tool is missing. What to check first: the builtin still works. Just drop the path and run plain time sleep 1, or install the package (often called time) if you truly need the verbose report.

time: cannot run frobnicate: No such file or directory time started fine, but the command you asked it to measure does not exist. Here frobnicate is not a real command, so there is nothing to run a stopwatch on. What to check first: your spelling of the command right after time, and that the program is actually installed.

No timing lines print, only the command's output This is not an error, it is a surprise. If you write time into a script with #!/bin/sh at the top instead of bash, some shells do not have time as a builtin and quietly do nothing special with it. What to check first: that you are in bash. On the command line you almost always are, so this bites mostly in portable scripts.

One message you will almost never see is bash: time: command not found. Because time is a bash builtin, it is baked into the shell and cannot go missing the way an external program can. If you ever DO see a not-found for time, you are in a stripped-down shell that is not bash, which is rare on a normal login.

Scaffolding off. No command is printed this time. You have every piece you need.

You want to know how long it takes the machine to do nothing for two seconds. Use sleep 2 as the thing being measured, and clip the stopwatch on the front so you get the three timing lines back when it finishes. You are looking for real to land near two seconds.

prompt: student@linuxcamp:~$ answer: time sleep 2 output:

real 0m2.002s user 0m0.001s sys 0m0.001s hint: Same move as timing sleep 1, but wait two seconds instead. Think time, then the sleep command with a 2.

That is the everyday move. You put time in front, and sleep 2 supplied a duration you could predict. So real came back near two seconds while user and sys stayed near zero, because the machine waited, it did not work. Your own digits after the decimal will differ. But that shape, real near the true wait and the two CPU lines near zero, is what you will see on any machine. You recalled the stopwatch move from memory, which is exactly the recall the real machine will ask of you.

You earned this cheat sheet. Every row is a form of time you just ran or met:

And the three lines you can now read on any machine: real is the wall-clock time that truly passed, user is CPU time in your program, sys is CPU time the kernel spent for it. When a command feels slow, put time in front and read real first.

time tells you HOW LONG a command took. It does not tell you WHY it was slow. That is a job for other tools later. But the first, fastest question, did this take a tenth of a second or ten seconds, is answered by typing four letters and a space in front of anything you run.

The practice terminal has shown you the shape of time. You have the three lines and the stopwatch move of putting time in front of any command. You have the pipeline form, the external /usr/bin/time -v, and the errors that tell you exactly what went wrong. Every one of those you typed yourself.

The Time module ends with one real Linux machine, the Time capstone mission. That is where you run time for real. A VM boots just for you, with its own live clock. It hands you objectives that use exactly what you practiced across this module: timing commands, watching them repeat, sleeping on purpose, and generating sequences. One difference from here: the mission shows no commands. You read the objective, you recall the command, you type it. That recall is what makes it stick.

Finish the other Time lessons, then go put a stopwatch on a real machine.

Practice time in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.