Black Magic – Demystifying the Command Line Interface


In a previous post, I wrote about how I migrated to Linux after many years running Windows. For most computer users with longstanding Windows experience, one of the biggest gripes against Linux is that it is not user friendly. For many such people, the mentality is based on hearsay, but for some, it is based on actual experience: What do you mean sudo?


Few things strike fear into the hearts of modern Windows users like the CLI, and it’s easy to see why. Microsoft has come a long way with its flagship product, the Windows OS. Each new version has endeavored to give the user a more pleasant experience than the last. It’s primarily the reason for the product’s massive popularity, in spite of its price, security vulnerabilities and other flaws. The Windows desktop user has become accustomed to the easy life. Pointing and clicking is the system’s lingua franca. Application software developers have not “helped” the situation. Nearly every useful program, however cryptic, has a Windows GUI provided either by its vendor or by a third party in an effort to make it more accessible. These advances have gradually led to the misguided notion that the CLI is an extinct creature from the gruesome past of  computer evolution.

Pretending that the CLI does not exist is perfectly harmless for the average computer user. I would even go as far as recommending it. However, any power user or software developer who avoids the CLI is doing himself a huge disservice. I should know, I did for the longest time. The CLI opens up possibilities that no GUI could ever provide. It lets you perform long and tedious tasks quickly. It lets you automate repetitive tasks. It lets you work the same way across different flavors of Unix. It lets you get really intimate with the machine.


After running Linux as my primary OS for quite a while now, I thought I should share my experience and the lessons that I have learnt growing familiar with the CLI.

Linux is the opposite of Windows in many ways. While Windows prides itself in its user friendliness and accessibility, Linux is unapologetically geeky, preferring instead to be viewed as a lean and efficient powerhouse whose singular mission in life is to get things done. To be sure, many projects have evolved over the years with the goal of making Linux a more accessible, general purpose operating system. The most prominent example is without a doubt the ever so popular Ubuntu Linux by Canonical Ltd. Yet Linux can never quite seem to shed it’s heritage as a programmer’s plaything, and as with Windows, this culture pervades the entire ecosystem. There are many Linux programs with which interaction is only possible through the CLI or clunky, halfhearted graphical user interfaces.

A new Linux power user or software developer quickly discovers that unlike on Windows, there is no wishing away the CLI on Linux. The usual reaction is usually one of disbelief, even indignation. But eventually the cold, hard reality settles. Some take off, whimpering and kicking their way back to Windows. A few brave ones stay. If you  are staying, here are six tips to make your CLI journey less grueling and more fulfilling.

1. Do not attempt to memorize commands

Besides cd and ls, there aren’t many other commands that you should deliberately try to memorize. You should let your subconscious handle everything else. I find it does a pretty decent job of helping you remember the ones you use most. All the rest can always be easily found, even without any external reference. I will show you how, shortly.

2. Understand the anatomy of commands

Some commands appear cryptically long and impossible to remember. They are, so do not try to remember them. But they can be understood. Shell programs are written to do one thing and do it well. They read from standard input (keyboard), perform some processing and write to standard output (screen). Optionally, they have options, which in turn may take arguments. To achieve something more complex, commands may be chained together using pipes(|). Each subsequent command then gets its input from the output of the one preceding it. Input and output may also be redirected to other places besides standard input and standard output, to files for instance, using the greater than and less than characters (<, > and >>). Here’s a simple example:

echo cli is fun | cut -c1-3 >> cli.txt

In this example, we use 2 programs echo and cut. The echo program accepts input from the keyboard i.e. the line “cli is fun” and outputs the same to standard output. This output becomes the input of the the cut command. The cut command has one short option specified, -c, which may also be expressed as the long option –characters. For most modern programs, short options are prefixed with a single hyphen and long options are prefixed with double hyphens. Prefixing a long option with a single hyphen leads to expansion, so that cmd -option expands to cmd -o -p -t -i -o -n -s. The result is 7 different short options for the cmd command. In this case, the -c option takes an argument of the form N-M, meaning cut from the Nth character to the Mth character. The output of the cut command therefore becomes just “cli” and is appended to a file named cli.txt by way of output redirection.

Nearly all CLI commands conform to the above pattern. Some commands may require that you first specify a prompt i.e. a word that gives context to the command. For example, all Git commands such as add, commit and pull must be preceded by the prompt git, e.g. git add, git commit or git pull.

3. Know how to find help

As I already mentioned, you should not try to memorize CLI commands. Many CLI programs ship with detailed manual pages that explain what they do and how they should be used. The CLI provides some very handy programs that let you easily get help from right within the terminal. In my opinion, these are the first commands any CLI newcomer should learn.

type: tells you the type of a given command

whatis: gives you a short description of what a given command does

man: lets you access the entire manual page for a given command

apropos: searches names and descriptions of manual pages

help: display help for shell builtins

4. Use aliases

Much of the power of the CLI comes from the fact that simple commands can be chained together to do more complex things. After using the CLI for a while, everyone finds there are commands that they type often. Such commands, when long or difficult to remember, make good candidates for aliasing. Aliasing lets you invoke a command or chain of commands by typing a shorter, more memorable name. For example, to print my wireless LAN IP address I use:

ifconfig wlan | grep inet | grep -v inet6 | awk ‘{print $2}’

This is obviously unwieldy and unnecessary to memorize, so I have it aliased to a much shorter  name: ipad. I also have aliases for Git, Maven, SSH and many other commands that I run frequently.

5. Create functions

Sometimes it is the case that the set of commands you need are executed one by one rather than chained together and therefore cannot be aliased. Not a problem. Such commands can be defined inside a function and then the name of the function becomes the means by which to invoke them all at once. Shell functions are easy to write, even for people without much programming experience.

6. Write shell scripts

Tasks requiring more complex logic are best implemented in shell scripts. Shell scripts are fully-fledged computer programs designed to run in the shell. They can contain control structures and break down big tasks into functions that call each other to implement very complex logic. At the very basic level however, shell scripting is just yet another way of assembling simple programs in interesting ways to solve a big problem.

There you have it. Go on and have fun with the CLI. As a bonus, here are link to my favorite website for learning the Linux shell.

Related articles


Why Should I Care? – Making Education Count


This isn’t exactly about software development. It’s about learning in general.

Do you ever get the sense that an awful lot of what they teach you in school doesn’t really make sense? Like you don’t see the point of it?

Who knows why they learnt calculus? Or types of rocks? A paltry few, I bet you. And yet there surely must be rhyme and reason to these things. Only we’ve been taught to never wonder what it might be.


Take pi, for instance. 22 out of 7, they told us. Approximately 3.142. Ahem!

So what? And how even? Who says the teacher didn’t just pull that number out of the thin air. And why should we care, anyway?

Ah, I see now, π x d. The circumference of a circle. That’s useful. Quite useful.

But wait a minute, it still doesn’t say what pi really is or where pi comes from. Pi, you can’t be that mysterious now, can you?

Or maybe we don’t really need to know. Doesn’t sound right.

For one thing we might forget the value of pi when we most need it. But couldn’t we always look it up in the textbook? Or ask Uncle Google? He knows everything, after all, doesn’t he?

No reason to worry.


Unless of course there is an earthquake and all the textbooks get buried under the rubble, along with your computer and your math teacher, God forbid – and you survive, somehow. But maybe then π, or the circumference of anything, will be the least of your worries.

Strong case for never needing to ruminate too much about this pi guy, huh?


Which is tragic, because pi is such a profound idea. Really, it is. Think about the guy who might have discovered pi. In those days they would probably place a string around a circle to workout it’s circumference. And he placed his string on one circle – and measured. Then on another – and measured. Then on yet another – and measured.

A pattern. He saw a pattern. A relationship.

For every circle of circumference c and diameter d, there existed an interesting relationship between the two. Aha, if you divided c by d for any circle, you got the same magic number! 22/7. 3.142. Pi.

Who needs the string anymore?


But it’s more profound than that. Think about the many lessons this teaches. It demonstrates how you could generalize through experimentation. It also introduces the idea of ratios between quantities and why they are important. Not to mention that it virtually eliminates any need to ever memorize the value of pi. All these skills are very transferable to other problem domains.

Yet your teacher likely didn’t teach you any of this, or even encouraged you to wonder why it is. And many more concepts we fail to appreciate fully.

Shallow. Hollow. Regurgitation of knowledge. Chewing cud. Sheepish, even.

Any wonder then that school ends up creating such poor problem solvers? So much content, yet not the foggiest inkling how it fits in the grand scheme of things. Not the flimsiest idea why we should care.

This thinking, this question, why should I care, I think, should help us all make better teachers and even better students of everything, software programming included. Next time your lecturer introduces a new course, ask him what really is the point of it and why you should care at all. Maybe you shouldn’t. Just saying.