In the previous instalment we looked how Unix-like operating systems like Linux and Mac OS X represent processes. We then went on to look at the commands for listing running processes, and filtering and sorting them in various ways. This time we’ll move on to controlling processes, specifically, starting and stopping them.

Listen Along: Taming the Terminal Podcast Episode 9

Starting Processes

Whether or not you think of it in that way, you’re always starting processes. Each time you launch an app, you’ve started a process. Also, each time you issue a command on the Terminal, you’re starting a processes.

So far, each time we’ve started a processes from the command shell, it’s been a so-called foreground process. We enter the command, this starts a new process, and that new processes gets control of our terminal until it finishes, at which time we get returned to the command shell. When we run very simple commands like ps, or ls, the processes take just milliseconds to run, so we don’t really notice that we lose our prompt for a moment while the new processes takes charge, does it’s thing, and then hands control back.

However, sometimes you want to start a process from the command shell, and not have it take control of your Terminal. A good example might be using a command shell to start a GUI app. You want the app to start, and to stay running, but you also want your command prompt back! We can do this using something called a background process. Should that process produce any text output, it will still show in our Terminal window, but as soon as we hit enter we’ll have our command prompt back.

Backgrounding a process is actually very easy to do, just add an & to the end of the command, and it will start in the background!

Lets illustrate this with a quick example. For this to work you’ll need to be on OS X, have FireFox installed, and have it not be running when we start.

First, lets start FireFox from the Terminal as a regular foreground process:

You’ll see that the FireFox GUI launches as normal, and that it outputs some information on what it’s doing to the Terminal. You’ll also notice that you have lost your command prompt. You can hammer the enter key all you want, but you’re not getting that command prompt back until the FireFox process exists and hands control back to your command shell. Go ahead and do that through the GUI as normal. Notice how the moment FireFox quits you get your command promote back.

Now, lets start FireFox as a background process:

The FireFox GUI will start just like before, and the same debugging information will be displayed in the Terminal window, but this time you just have to hit enter to get your command prompt back. Firefox is still running, but you have your command prompt back.

If you scroll up you’ll see that the very first piece of output when you ran the command was a line consisting of a number in square brackets, followed by another number, something like: [1] 1714

The number in square brackets is a counter for the number of background processes the current command shell is running, and the second number is the PID of the new background processes, in this case, FireFox’s PID.


You can use a command prompt to quickly check your FireFox version number without even having to launch the FireFox GUI with:

Also, when you launch FireFox from a command shell you can pass it flags and arguments to alter it’s behaviour, for a list of valid options run:

On Unix and Linux it’s normal to launch GUI apps from the command line by backgrounding them, and as you can see, it works on the Mac too. However, the Mac has another, better, way of opening things from the command line that other versions of Linux and Unix don’t have, the open command.

The best way to think of open is as the command-line equivalent of double-clicking something in the Finder. when pass open one or more files as arguments it will open those files using the default app for their file type, and as an added bonus, it will automatically background and apps it starts, so you don’t even have to remember the &! Note that if you pass open a folder rather than a file it will open the folder in a new Finder window.

A very handy trick is to use open to get a Finder window showing the contents of your command shell’s present working directory as follows:

Another useful tip is to use open to quickly view hidden folders in the Finder. On recent versions of OS X, where the Library folder is hidden, I often use:

As well as opening things with the default app for their type, open can also open files or folders with any other app that supports the given type. The -a flag allows you to specify the app the item should be opened with.

I do a lot of Perl programming, and I have two apps installed that I regularly use to edit Perl code. I have OS X configured to open .pl and .pm files with Komodo Edit by default. Komodo Edit is a nice free Perl IDE, and I do all my big programming jobs in it. However, being a big IDE, it’s a bit of a hog – it takes so long to open that it has a splash screen! So, when I just want to make a quick edit, I prefer to use the light-weight Smultron editor instead. I can use open with the -a flag to specify that I want my Perl file opened with Smultron using a command something like:

Similarly, if I was using a computer that didn’t have Smultron installed I could open the Perl file with TextEdit using a command like:

That’s all we really need to know about starting processes, so lets move on to ending them.

Ending Processes

The command to quit a process is kill, which sounds very draconian indeed. Despite how scary it sounds, you don’t have to be overly afraid of it, because if used without flags, all it does is politely ask the process if it would please quit. In other words, it’s the command-line equivalent of cmd+q, or selecting Quit form an app’s menu.

The kill command needs at least one argument, the PID if the process you’d like to end. This is where the ps and top commands we learned about last time come in very handy (or indeed the Activity Monitor app of you are on a Mac). Note that you can use kill to end as many processes at once as you like, just keep adding more PIDs as arguments.

Let’s work through another example, using FireFox again. We’ll start by opening FireFox and backgrounding it with:

Before we can quit FireFox with the kill command we need to know its PID. We can either scroll up and read it from the first line of output, or, we can use the ps command to get it. Since we started FireFox from the terminal, it will show up when we use ps without any arguments at all.

Once you have the PID you can quit FireFox with (replacing [the_PID] with the actual PID of course):

You should see FireFox exit, and the next time you hit enter on your Terminal you should see a message telling you that a process you started and backgrounded has ended.

Finding PIDs can be a bit of a pain, so you’ll be happy to know that you don’t have to! There is another command for ending processes that uses process names rather than PIDs, it’s the even more scary-sounding killall command.

For what seems like the millionth time today, lets start FireFox and background it:

Rather than looking up it’s PID, lets now exit it with the killall command:

Note that you need to be careful with killall because, as its name suggests, it will kill ALL processes with a given name, not just one!

Dealing with Stubborn Processes

Up until now we’ve been polite, and we’ve used kill and killall to ask processes to please quit themselves. When an app crashes or hangs, that won’t get you very far. If the app is so messed up it can’t deal with mouse input anymore, it’s also not going to respond when kill or killall politely ask it to stop.

When this happens, it’s time to bring out the big guns! Both kill and killall take an optional argument -KILL, which tells kill/killall to instruct the OS to terminal the process, rather than asking the process to terminate itself. ONLY DO THIS AS A LAST RESORT, YOU CAN LOSE UNSAVED DATA THIS WAY!

Note that on older Unix systems killall didn’t exist at all, and kill only took numeric arguments. The old numeric equivalent of -KILL is -9, and both kill and killall on OS X (and Linux) will accept this old-fashioned flag as well as the more modern -KILL.

Before we finish I want to reiterate how importan it is to always try kill and killall without the -KILL option first. Think if it this way, it’s basic good manners to ask the process the please leave before you call the bouncers over to eject it!

Next Time …

We’ll be re-visiting processes again later in the series, but we’re done with them for now.

In the next instalment we’ll be taking at look at the built-in manual that comes with every Unix/Linux OS, including Mac OS X. You don’t need a book to tell you what flags or arguments a command expects, or what exactly they mean, you can find it all out right from the command shell, even if it takes a little practice to learn to interpret the information.