dcsimg

The Importance of Command Line Literacy

The oldest interface is still one of the best. Learning about shells and utilities can pay off for jobs where they're the fastest or most flexible.

Have you sat down with that grey-haired system administrator and watched what’s happening as her (or his) fingers fly over the keyboard? Ever wondered why they’re still Stuck In The Stone Age, typing text instead of using the obviously easier mouse and menus? Suspect that person is a geezer who can’t learn new techniques?

Maybe they did learn Linux (actually, Unix) before everyone had windows on a monitor. But there’s a reason why they keep a terminal window (or ten) open on their desktops: this is a power platform that can be the fastest way to work. It remembers what you’ve done (so it’s easy to repeat and/or modify), has built-in programmability (need a loop? no worries!), and gives you full access to the library of hundreds of Linux utility programs that were designed for just this environment. A terminal and utilities do jobs that a GUI can’t touch.

Less power than your wristwatch

The Linux command line was born around the time Linus Torvalds drew his first breath: in the days of small Unix systems with tiny amounts of memory. Back then, a tty was a teletype — those clattering machines that also sent and received telegrams over 110-baud lines. Using Unix meant typing on a keyboard and waiting for the (often-busy) system to respond. Every byte and CPU cycle were precious. The Unix command line evolved to help people cope with this environment.

Typing ahead

In these days of speedy systems with enough power to burn that you can have 3-D multicolor displays which morph with your mouse, the typeahead feature of Linux device drivers can still be worth knowing about.

Typeahead means that the memory buffer which reads your keystrokes and passes them on to the kernel can read input and save it until the rest of the system is ready to receive it. This was very useful in the days of super-slow processors that could barely cope with the keyboard interrupts generated each time you pressed a key.

Once you’re confident on the command line, you can still use typeahead today. For instance, if you’re trying to coax work out of a remote system through a congested network link, you may not need to wait to see a response. If you’re typing simple commands at a shell prompt, or using a keyboard-driven editor like vim that you know well enough to trust the commands you type, try typing ahead! It doesn’t always work: for instance, keystrokes like CTRL-C or CTRL-Z flush the typeahead buffer. But typeahead is still available, ready to receive commands at molasses speed and execute them when the processor is ready.

Not the only way

We aren’t saying that you’ll only want to use the command line. Understanding where it’s useful and how to use it will let you choose whether to use your terminal window or a GUI.

Think (twice?) before you type

One pitfall for new command-line users is this: Utilities were born in the days when you wouldn’t want to wait (and wait…) for a system to ask “Are you sure?” before, say, removing a file. So it’s best to think before you type — or, at least, to double-check before you press the RETURN key to run a command.

Once you’re used to decisiveness by default, the constant pop-up confirmations of a GUI can actually be frustrating.

So what?

Why would you want to type on a command line instead of (say) choosing commands from a GUI menu? There are more reasons than we can cover in three pages. Here are some of the best:

  • Linux utility programssort, cut, join, and hundreds of others — are powerful and flexible tools that are ready to run with a few keystrokes. Options let you fine-tune (or completely change) how utilities work.
  • Powerful I/O redirection lets you save data to files, read data from files, and connect a series of utilities together in a pipeline that lets you custom-build exactly what you need… again, with just a few keystrokes. GUI applications — which have to pack all possible operations into a set of menus and checkboxes — can’t be nearly as flexible or powerful.
  • Linux commands can operate on many files at once. Filename completion lets you specify filenames by typing a few characters and the TAB key. Some GUIs have that feature too. But most GUIs don’t have wildcards, which let you specify one or many files with just a few keystrokes. The pattern [A-Z]*.txt matches any filename that starts with an uppercase letter and ends with .txt; that could be many files. ([:upper:]*.txt handles non-English filenames too.) Use /home/*/data0[0-5] to match all files named data00 through data05 in all directories under /home — for instance, /home/amy/data01, /home/randolph/data06, and so on.
  • A shell is actually an interpreter for a programming language: the language of command lines. It puts powerful loops, tests, variables, I/O manipulation, error-trapping, and more at your fingertips when you type a command line.

    Put these same command lines in a script file, and you have a shell script — which lets you repeat those stored commands anytime you want to. It’s the same language from the command line or from a script file. Learn the shell “language” and you can use it both places!

    One of the authors of the Apress book “From Bash to Z Shell: Conquering the Command Line” gave a good example of this. “Earlier this week we had to rearrange a bunch of source files … arranging according to newer directory structure conventions. Lots of little jobs like renaming files to lower case would be really laborious from a GUI. From the shell I could do all the stuff on the fly as fast as my colleague explained what needed doing. He was quite impressed and it’s convinced him to try to learn more about it all himself.”

  • Command substitution lets you use the output of one command as part of another command line. If you haven’t used a shell before, this is hard to explain… but, trust us, it’s very powerful. For instance, you can run a file-search program like find, then run another command on the files that find found.

This kind of flexibility is unheard-of in a GUI menu system.

Behind the scenes

If you’re new to the command line, understanding some basics can help you fit the pieces together.

On modern systems, the old teletype device has been replaced by either a console terminal (which fills your screen — like the virtual terminals that appear when you press Alt+Fn or Ctrl+Alt+Fn; see the console manual page for details) or a terminal window (which is like other GUI windows).

Running “inside” the terminal is a shell. A shell is a Linux program that’s designed for running both internal “built-in” commands (like cd to change the shell’s current directory) and external commands (like grep, perl, vim, and many more). There are several different shells; bash, tcsh, and zsh (“Z shell”) are probably the most popular, but you can choose whatever shell you like.

A shell is a program like any other on Linux. So a shell can run another shell; that’s the situation when you run a shell script (a text file with one or more command lines, which start with a command like cd, grep, perl, vim, …).

A shell does the following steps, over and over:

  1. Unless it’s reading from a script file, it outputs a prompt (like $ — or anything you set it to) and waits for step 2.
  2. Reads a command line from the terminal (followed by the RETURN key) or from a script file.
  3. Parses (interprets) the command line to find the command name(s), special characters like * and ? (wildcards that let you specify one or many filenames without much typing), | and > (redirection symbols, which route programs’ input and/or outputs).
  4. Runs the command(s) and waits for them to finish.
  5. Repeats the steps for the other commands until the script file ends, or the user types exit or CTRL-D. Then the shell program terminates — and the terminal window closes, or virtual console prints another login: prompt.

Examples

We can’t give many examples in a three-page column that also explains the basics. If you’d like to see of what you can do in this feature-rich environment, browse through some of the past six years’ Power Tools columns.

Being able to use any command in a loop — to do something repetitive, with just a few command lines — is one of the most obvious reasons to use a shell instead of a GUI. Here’s a loop that finds every filename ending with .c in the current directory and makes a copy with OLD_ preceding the filename. (The -p is an option that tells cp to give the copy the same last-modification date as the original file.) Linux utilities normally run silently unless they have errors… but, if you wanted to see what files cp is copying, you could add the -v or --verbose option:

$ for f in *.c
> do cp -p $f OLD_$f
> done

The $ and > are prompts. These tell you that the shell is waiting for commands. You can customize prompts to show much more information: the name of the current directory, the computer name, your username, the date and time, and almost anything else.

To repeat the previous loop at some later time, you could navigate up in the shell’s history list by pressing the up-arrow key on your keyboard — and, when you see the loop you typed before, press RETURN to re-run it. It’s also possible to edit the loop interactively at this point. Or, you could use one of the history commands available on old teletypes. This command repeats the previous for loop:

$ !for

Not all shells will let you repeat an entire loop with !for; they may only repeat the first line. The shell will show the loop commands, then re-execute them. This is an example of why Linux commands generally do what you ask without confirmation: in this case, cp will replace the previous backup files with the new ones. (If you didn’t want that, you could have added a cp option like -i, “interactive,” which asks before overwriting.)

Want to back up every filename ending in .c in the entire directory tree — which could be tens or thousands of directories? Replace the *.c in the previous loop with command substitution and the find utility. Here we’ll change the cp command line to make copies whose names end with .bak:

$ for f in $(find . -name '*.c' -print)
> do cp -p $f $f.bak
> done

That loop has a couple of subtle problems that you’ll understand once you learn more about how shells work. (You could add -type f to tell find to copy only files — not directories whose names happen to end with .c. Also, if any names have spaces or special characters, you should be sure they’re handled correctly.) The Z Shell has a built-in ** recursive-matching operator that’s easier than find. Here’s the previous loop using Z shell:

% for f in **/*.c
for> do cp -p $f $f.bak
for> done

This is an example of the power of different shells: if you know how to use more than one, you can choose the best shell for a job. (Many Linux users only learn bash… and that’s plenty!)

Maybe your IDE (programming environment) has a function that can copy your source code. But can it copy any or all directories? Can you choose the backup method, and whether the backups keep the original timestamps? Can you add conditional tests to choose which files are backed up — for instance, only files modified in the past day, or only files with more than 100 lines, or only files containing a call to the function foobar(), or …? If you can, that’s a sophisticated IDE! But what if you want to make a zip or tar archive instead of a backup? Or if you don’t want to copy the files; you want to rename them? Or …

Or maybe you should take the time to learn the fundamentals of shells and utilities. Once you learn the basics (like for loops) you can use those same fundamentals with the hundreds of utilities to do thousands of operations — with just a few keystrokes. Grab a good book (like the Apress book mentioned earlier; shameless plug: this author wrote part of it) and get ready to be a (grey-haired?) Linux guru yourself.

Comments on "The Importance of Command Line Literacy"

zamin

This is so true. Changing file name is the most reason I’m still using my console box.

Reply
sargetech

The command line is power!!!

Reply
munguia.carlos

Is most faster work in the command line , linux is the best

Reply
benukemenam

In my opinion, the command line is of key importance in all unix flavours.

Reply
garycarneiro

command line is fun thanks to guys who developed bash and bash completion feature !

Reply
unixmarcelo

Command line is very important POWER tool for linux UNIX and MS- Windows. Yes you read corect, this is for Windows one important tool too.

Reply
hexram

As a seasoned UNIX/Linux user and teacher, I find that most users prefer GUI over command line because they don’t like to think. Even experienced users that configure their working environment to suit their fancies fall in this category when their startup scripts resemble “War and Peace” as more and more aliases, functions and the like find a way into them ‘just because they are cool’. Granted, technology tends to avail this behavious as hardware crunches more and more CPU cycles by unit time and end users doesn’t suffer from waiting time over their terminals anymore. Maybe, while some rain falls outside your office and you feel bored, instead of walking down to the coffeemaker, give your startup scripts a look or two to remove obsolete, redundant or cancelling definitions and you will refresh your knowledge and also will speed up a couple of nanoseconds your waiting time at the console.

Reply
ankit1983

CLI is the best interface for anybody who wants to finish job smartly.

Reply
frankmesen

If you know what you are doing, the CLI is an excellent weapon.
If you don’t know what you are doing, the CLI is an excellent weapon!!!!!!
Weapons should be handled carefully.

Reply
tesla.coil

hi i have been using windows for over 7-8 years and i recently installed ubuntu and been using it from a month ( in GUI mode) and recently i happend to join some networking classes ,where iam currently learning RHCE ,what i really loved abt it was the commands! the shell commands! i never used the CLI mode( in windows obviously) and never knew that learning to use CLI mode be so much fund and rewarding as well , now am all over it and really loving the unix commands ,its been just couple of weeks since i started using the bash commands and am working pretty hard at it,well i wasnt taught much abt the basic unix commands considering the fact that the more importance was over system administration and network administration ( in the RHCE course) so i got my self a book on unix shell programming and started reading it, what i love abt CLI mode is i exactly know what am doing and what the possible outcome can be ..which doesnt happen in the GUI mode! well thanks a lot for the article it was really worth reading and lastly can u guys advice me on how to master the command mode :D

Reply
lnxrcks

The difference between CLI and GUI is the same as the one between a language and a phrasebook. Using the CLI, you can tell your computer exactly what you want and get the appropriate answer. Using a GUI application, you can only tell your computer what the GUI programmer has defined. Needless to say, it is well worth the effort to learn how to speak efficiently to your computer.

Reply
snickels

I believe each, gui versus command line, both have advantages and disadvantages. Command line is more powerful from the standpoint that its commands let you do a lot, but that also makes it a bit harder to learn because there are so many commands and parameters to remember. With the command line, you have to be quite a bit more aware of typos. Doing a simple “rm f*.dip” when you ment to do rm “fp*.dip” could make your day more difficult. A couple days later you come back and wonder where did all the files starting fa*.dip go??? You needed them. Deleting the files using a GUI might not be as fast, but you do get immediate visual feedback of the files marked for deletion. Many times I need to find out the IP address of my Windows box. Do I go through all the GUI menus to find it? No, I open a command prompt box and enter “ipconfig”. So, I like the command line for some things, and I like using a GUI for other things. I think they can (and should) coexist.

Reply
framness

I run Slack at home and when I log in I bring up KDE, but when working on my system (or goofing around) I always have at least one (often multiple) CLI sessions open.

One thing that IMO makes Unix/Linux superior is it is a true data-processing system, you can work applications interactively or using the CLI you can create powerful batch or scheduled processes. If I was doing my web development on a windows system I would have to manually FTP & manage website backups daily. With Linux I have a system already in place and I use a combination of Perl and bash to do that work. I like the idea every application I have I can think of can be run via CLI calls or via GUI bolt-on in my preferred windows manager.

If all you are doing is GUI work than it may not make sense to use Linux to really get the most benefit you have to use the CLI.

Reply
dbierer

I find the CLI most useful when using ‘ssh’ to manage remote systems and also creating ‘cron’ jobs. Set up a script for a customer the other day, triggering at midnight, which uses ‘find’ to search for files older than 30 days and remove them. In another case I had to change the filename extensions for a whole slew of files. A simple ‘ls’ command, piped to ‘cut’ with ‘.’ as the delimiter and I had my raw filename. Piped that output through a loop and all my files had new extensions. Heady stuff :-)

Reply
zayar43

The best way of linux life!!!

Reply
mrhammer

I have been working IT for 20+ years. Mainframe, unix, windows, dec/vax, and other all offer CLI as PRIMARY means of command and control. GUI vs. CLI is old comparison. I like the fact that GUI can make you productive for relatively common tasks (browsing folders, launching applications, simple file managment). for complicated tasking and goals – all programmers should know CLI for systems they support. It is like knowing long division vs. using a calculator. Real appreciation for the operating systems comes from the command line. GUIs are notorious for isolating the IT professional from the OS (especially unix).

thanks

Reply
garzon.lucero

I know white spaces and the like should be avoided in filenames. That said, it is sad to see

$ for f in *.c
> do cp -p $f OLD_$f
> done

rather than

$ for f in *.c
> do cp -p “$f” “OLD_$f”
> done

in an introductory example. This stuff is particularly confusing for beginners, let alone when it appears incorrectly in a magazine of record.

Reply
tbenson

I am a newbie…well, have been using Linux for basic computing needs for about 2 years now, but have recently started digging into the wealth of knowledge from sources such as this article. I am thoroughly impressed with the Linux community — the developers, users…everyone. This is a very useful article and I will look forward to more like it. Thanks.

Reply
jeanerpp

Command line is good.
It is very common that GUI is not available.

Reply
tdyess@dysr.com

rm -rf /*

Reply
tdyess@dysr.com

^^ PS: If you don’t know what that means, don’t type it into your console.

Reply
usernam

A bit offtopic, but related to Bash autocompletion. Comments have been disabled for the Autocompletion article, but for anyone interested, there\’s a Rational ClearCase completion script available at http://jan.tomka.name/project/clearcase-completion-bash. Cheers, Jan.

Reply
helmandollar

Cmd line is so much more powerful than most people give it credit for. I just wish more people took time to learn it. I think thats one of the things that annoys me about windows users, if it dont have a .exe attached to it they are clueless.

Reply
grabur

People in the main, don’t like to type. I think that’s the thing that puts people off the command line.

So the first thing I introduce newbies to is BASH auto-completion, shell history, man pages for commands and file system navigation.

The most difficult thing is knowing where to start. Get used to glancing at man pages alot, and using a search engine to find examples.

In a GUI environment you are presented with options to pick from. I can quickly scan toolbars, menus and program preferences and get a good feel for a program.

In some ways the command line is a little less intuitive than a GUI. But in some ways it’s more so. Once you appreciate it’s power, and learn a few of the most common commands you can’t live without it.

Reply
cwcarlson

Interesting that this thread was started 2 years ago, and it’s still attracting posters.

I’ve been using *nix command line since the late 1970′s. Knowing how to type is a plus, but the original developers of Unix didn’t know how, and they developed an entire language (C) and operating system. Thus the reason most commands are 2 characters long.

In my experience, Windows are useful to present information and for users that need menus. Considering the complexity of tools these days, most of us need those pull-downs, popup windows and help bubbles.

Command line is the best for those of us that want to do things quickly and know what we’re doing. This is not to imply that we’re better than others, just that we’ve been doing it for so long, it’s a lot easier to do ‘ls -lt blah/blah/blah’ than to open an explorer window and click down the hierarchy, change the display option to show details and then sort by date/time.

When working with young people freshly out of college, I often hear the comment, “Wow, that was fast. Maybe I should learn how to use the command line.”

I must have 50 scripts that I have written to do things I often do.

On the other hand, I have yet to master SAMBA. It’s far easier to use a windowed wizard to walk me through the configuration.

Ah, the days of the past when we learned command line using the program called ‘learn’. It was written by Kernighan, but the source has disappeared (at least I can’t find it in the usual places).

Reply
nrarnot

People who don’t “get it” when steered in the following way are beyond help.

Imagine that you’ve got a GUI tool for administering (say) users and a command line tool. You need to do something trivial to a subset of them. You need to avoid doing the wrong thing, or doing it to the wrong account. The wrong thing, or to the wrong account, are legal operations so you won’t see any error messages if you do.

For doing it once ot twice, the GUI tool may actually be faster.

For doing it a few times
# <command> user1
up-arrow to recall the command, change user1 to user2, then user3, …

For doing it ten or so times
# for x in user1 user2 user3 … user10 ; do command $x ; done

For doing it many or very many times, with the users specified by a file of userids

# for x in cat selected-users.list ; do command $x ; done

I defy anyone with an IQ over 100 to perform the same operation on say 125 out of 750 instances of an entity through a GUI interface without making any mistakes and without losing the will to live after the first fifty.

Reply
nrarnot

Drat – Linux Mag’s interface has deleted the back-quotes from around “cat selected-users.list” in the above!

Reply
grabur

@nrarnot, perhaps you should have tried the dollar:

$(cat selected-users.list)

A good point re: the tedium of repetition – that is when it starts to hurt to hurt with gui tools.

Reply

Major thanks for the blog. Great.

Reply

Major thanks for the article.Much thanks again. Cool.

Reply

There is noticeably a bundle to know about this. I assume you made sure good points in options also.

Reply

I’m truly enjoying the design and layout of your website. It’s a very easy on the eyes which makes it much more pleasant for me to come here and visit more often. Did you hire out a designer to create your theme? Outstanding work!

Reply

I’d should test with you here. Which is not one thing I usually do! I take pleasure in studying a submit that will make individuals think. Also, thanks for permitting me to remark!

Reply

Nice post!!! This site simply keeps me returning. I enjoyed the work which you put into it and also cherish reading all of the articles. Thanks a lot a bunch as well as keep the excellent work up!!!

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>