Being a console geek in Linux

This is the first in a series about using the "command line" in Linux. It is also about knowing when to use a gui instead. But before going into any of that we need to understand what is meant by a "command line" application. You'll find that as we explore that idea, a lot of things that are not really true 'cli' (command line interface) apps arguably count as cli, including menu driven console based apps and even gui apps. This will be controversial.

Let's start with some basic definitions. If anyone has any problems with any of the following just let me know. Consider this a first draft subject to revision!

Console/Virtual Console/Virtual Terminal
The term "console" and the term "terminal" can be thought of as equivalent.

This is a computer interface that uses the command line prompt at which the user types commands, and no graphical capabilities beyond those able to put characters on the screen. Calling this a "virtual console" is misleading and the reasons for the use of the word "virtual" are unimportant. This is the real thing. This is what happens when you turn on your *xnix based computer and no graphical interface comes up and instead you've got a black screen with a prompt waiting for you to do something. In Linux, you can usually get to a "virtual console" by typing Alt-Ctrl F1 (You'll have to sign on as a user on your multi-user Linux system). Alt-Ctrl F1 through F6 will usually get you to a series of different virtual consoles, and Alt-Ctrl F7 will get you back to your GUI desktop. I'm not prone to using the Virtual Console at all. The quality of the character display is not as good as the quality of modern GUI-based interfaces, given the ability of computer screens to have high resolution and finely tuned fonts. It simply looks better and works better to use the windows, even when using the command line. There are other reasons as well. But, it is a good idea to be familiar with the virtual console because sometimes that is all you've got.

The good news: Think of the virtual console as the Linux equivalent of the spinning smiley face on a Mac or the Blue Screen of Death on Windows. Except you can do stuff on it. When you have a virtual console, you have the ability to command your computer (Hey, they don't call it the "command line" for nothing!)

Below is a photograph of a virtual console, running Linux.

i-6558fa9d9e41948970321e7273552ea3-console.jpg

Terminal Emulator (e.g. xterm)
If a "virtual console" is an actual console (and it is, trust me) then a "terminal emulator" such as "xterm" emulates a console. (Yes, that makes it a "virtual console" but let's not go there just now...)

A terminal emulator runs inside a window which, in turn, is managed by a window management system such as "x" and probably further managed by a "desktop" (like gnome or kde). Those details are unimportant. The point is that everything that can happen inside a virtual console can also happen inside a terminal emulator, but the terminal emulator, being in a window, can be resized, moved around, etc. and otherwise be more usefully employed. Perhaps most importantly an emulator can, if it's a good one, be adjusted with respect to font size and appearance more easily than a virtual terminal (which may be very limited in this way). You can also cut and paste from and to emulators.

In the screenshot below, a number of terminals are open on a GUI desktop (gnome, in this case) all doing different, interesting things.

i-dc3a33f3c6ba65bf390b578cd6325b13-cli_apps-thumb-500x208-56575.jpg

cli (Command Line Interface)
One would think that a "command line interface" is just the interface you get when you use a terminal. That is sort of true, but not really. Technically, you are using a cli when you get the software to do stuff by typing at the console. If you have a menu-driven (character based) program that allows you to use either the arrow keys on your keyboard, or in some cases, a mouse, that is not a cli because you are not tap-tap-tapping on the text part of the keyboard.

In this clip, Scotty uses a cli-like interface within a gui to make some wtf. In German.

Even though many will classify a program or utility as a "cli" only if one uses exclusively keyboard commands, I would say that using the "command line" or the "console" or the "terminal" in ways that include non-pure cli methods counts as "command line" interfacing. In fact, I would go beyond this (and we'll come back to this below): an application that allows and especially encourages and perhaps even requires tappity-tap to do most or all things, even if he application is presented in a gui, is close enough to cli that I include such apps in the cli/console family. I'm speaking, of course, of a handful of programs such as S (the statistical program), certain math software, and emacs.

GUI (Graphical User Interface)
A graphical user interface is a system that facilitates the interface between user and computer using visual graphic capabilities of a computer together with a mouse (the mouse may be optional to the user but is always designed into the GUI). Most apps are displayed in one or more windows which have standard resizing and moving capacities, and various aspects of the interface are typically controlled across the system by configu... wait, wait, hold on a second here! Why am I explaining to you what a GUI is? You already totally know this, let's get on with it.

For now, suffice it to say that when we say "GUI" we don't mean a menu driven cli. Also, GUI is in all caps by tradition. cli is not, I suppose because on the command line, we avoid upper case letters.

GAK (Getting All Keyboardy)
GAK is a philosophy more than an interface technology. GAK is simply the practice of avoiding the mouse and sticking to the keyboard when possible, which may involve learning and using "keybindings" that move around a cursor or do other things and it may involve using typed command input instead of menu-mouse selection methods. There are some pieces of scientific software that just beneath the surface run on commands, and the menu is just a way of getting at the commands. In some of this software, you can expose a command prompt and use that instead of the menus. In most software, even a web browser like Firefox, you can learn to be more keyboardy and thus probably save yourself some time and impress your friends.

The real point of much of this discussion is not GUI vs cli, but rather, how to GAK. Seriously.

The following definitions link the above concepts to actual applications, utilities, and stuff.

Shell Command
A shell command is a single word followed by optional parameters, switches, options, etc. that one enters at the cli in order for a thing to happen. Shell commands are often thought of as being of certain types depending on their relationship to the kernel of the operating system, but that is really not important. In the old days there was a handful of "system commands" or "shell commands" and an additional set of commands one would enter on the command line to get some result. At some levels this is a meaningful distinction, but for the modern cli-savvy end user it is not. So, I will violate the sensibilities of a lot of people when I say this, but ls, convert, cal, and screen are all shell commands. Sorry if that offends you. (Feel free to vent in the comments, maybe you can change my mind.)

A special and interesting class of shell commands are the "one liners" which are more complicated than the usual command and often involve more than one single command strung together. Many shell commands are system maintenance related, such as: "sudo apt-get install wtf" which would install the program "wtf" on your computer after you enter your password. Some are actual programs that are not system related but are so simple that a single command entered at the keyboard is sufficient. For example, "wtf is wtf" is a single line that runs the program "wtf" which returns definitions for acronyms.

In my efforts to GAK, I've collected a handful of simple cli commands, and with an xterm open on one of my workspaces I can alt-ctrl-arrow key to a blank prompt at any time and find out what my Google calendar has for me today, what historical events are coming up, the definition of a word from a dictionary, an acronym, the weather conditions at the cabin or the forecast for the next few days, or how much storage space I have left on my hard drive.

cli App
A cli application is bigger than a one line command, but does not use additional interface techniques other than the command line. Something like the statistical package 'r' or gnuplot qualifies as a cli app because there is no menu and everything is GAK-ed out to the nth degree.
Menu Driven Console App (TUI)
Sometimes called a Text (or Terminal) User Interface, this is either a special case of a cli app or a different beast depending on how pure you want to be about what the cli is. I consider these to be apps that use the console to present what is essentially a graphical interface that is made up of ascii codes. Midnight Commander (mc on your console) is an example .... it is a file manager program, and in fact, is one of the first apps to get even slightly gooey and demonstrate the utility of non-linear non-command line utilities (it was originally called "Norton Commander"). One way to think of these apps is in relation to their command line counterpart. So, ls vs mc is one such comparison. To see the processes running on your computer, you can use ps (type "ps aux" to see a list of everything running). This shell command can be used to grep your processes with the ultimate goal, for instance, of killing them. (Only the bad ones, of course). But to get a more interactive form of the same information, we have "top" -- if you type 'top' into your console, you get an interactive character based application with a primitive menu.

Some menu based programs can be made to work with a mouse, some not, but that is not very GAK.

Tom Clancy Popout
This is a special case of console app or shell command. I've placed an illustration below. This is where you are going tappity-tap on the command line and this causes a graphical thingie to come flying out and appear on the screen. Perhaps this will be a satellite image of a terrorist training camp in North Africa. The guy standing next to you says "Zoom in on that hut" and you go "tappity-tap-tap-tappity-tap" and squares appear around the hut and cause the hut to get bigger and bigger. Then the guy standing next to you says "That's the one... It's a go. GO GO GO!" and a bunch of guys jump out of helicopters and .... well, you get the point.

Tom Clancy popout apps are far too infrequent. There needs to be a lot more of them.

i-63ff2fc362d80bf4256a5fcff30b841f-clanceymode-thumb-500x208-56578.jpg

GUI cli-terminal-like GAKy app

This is the type of application that may or may not make full use of the GUI but that uses primarily keyboard commands to operate. Even though emacs now has a menu that can be operated by a mouse and toolbars with buttons on them, no one ever uses them, and most emacs activity is done by using the keyboard. Think of it this way: A person who has only ever used emacs on a "virtual console" or within an xterm can switch to the GUI version of the program and never change a thing, other than being annoyed at the screen real estate being taken up by the button bar. There are not many apps like this, and there should be more. Nonetheless having the definition handy is important because one of the most important apps a GAKy cli-ist is likely to use is the GUI cli-terminal-like GAKy text editor.

Now that we have some basic terms defined, let's look at software that might be usefully run on the command line.

I. X marks the spot.

The first rule in using console based software on a modern Linux computer is this: Run the console in X (the windows server, along with a desktop such as Gnome or KDE or whatever), with the consoles running as an emulated terminal as opposed to a real terminal. Real terminals are available to you from within gnome or KDE by typing Alt-Ctrl F1 through F7 or so. Chances are your "x" (gnome, KDE) is on the console that exists at Alt-Cgrol F7. But that is not how you should run your console programs because you lose nothing by running emulated terminals under X, and you get the following advantages:

1) You can adjust how it all looks a lot better than you can with actual consoles;
2) You can integrate activities between programs more easily;
3) There are some things you can't do in a console, despite what certain fanatics may claim. Try browsing the web with lynx or wget for a while. You'll be back.

II. Make use of desktops and other hierarchical constructs.

Instead of having different virtual consoles with different things going on, you can get the same effect ... which, on your laptop means having a full screen console ... by using multiple desktops. Most users are pretty happy with the usual default of four desktops. If you want to do a lot of cool console stuff, consider making yourself eight desktops. This does not mean you won't be running windows (and tabs within windows) but it will give you the opportunity to make full use of the mindblowing potential complexity available on your linux box. Think about it. You have:

1) Desktops (aka "workspaces")
1.1) Consoles or browser windows
1.1.1) Tabs in browser windows, and if you have the right emulator, in consoles
1.1.1.1) Screen or other methods of spawning processses within consoles.

Deep. Hierarchically speaking, anyway.

III. Use certain console apps as X apps anyway

Even though you will be using console applications for many purposes, consider using emacs in X as your processor. If you use gnome, use the provided file manager simply because its integration to the system is so powerful that you will lose functionality if you don't. The same is probably true for KDE

IV. Focus on using these apps

1) Despite what I say above, have at least one quick and dirty console based text editor and use it for one or two limited purposes, mainly for browsing and doing limited editing on specific, selected files. There is no real reason to do this other than that it will look cool.

2) Alpine or another text based email app. Console based email apps can be annoying now and then. GUI email apps are annoying at all times. Be annoyed less.

3) Calendar and scheduling apps, including one that gives you access to Google Calendar.

4) A console based calculator.

5) The package manager for your distribution in cli form.

6) Image processing software such as Imagemagick.

Some functionality is better addressed by cli apps. Some functionality is better addressed by GUI apps. Other functionality is best addressed either way, depending, in which case you may find knowing both is a good idea.

When I look at the GUI version of Google Calendar, I become disoriented and confused by the way it is displayed, and the way it scrolls or fails to scroll. There is an "agenda" view, but that requires messing around with views. If I want to know what is going on over the next couple of days, I use a cli that spits out an agenda. I can spit that out and send it to my wife in an email very easily. Yet, when I want to make, and otherwise muck around with, appointments, the web based GUI is better.

I could say similar things about email and other applications as well.

Over the next few days I'll be discussing various specific cli/console or GAK applications.

Next: Whither the weather? Linux CLI solutions

More like this

"...you can learn to be more keyboardy and thus probably save yourself some time and impress your friends."

You're right, I impressed a lot of my friends with my keyboardy way of alternating windows with Alt+Tab...

and shift-alt-tab to cycle backwards

Tom Clancy popout? Oh, if only ... in reality whenever I go to demonstrations of some wonderful system or other I have a very hard time not giggling all the time because apps rely too much on the mouse or that horrible touchpad whereas some very old systems accomplished similar tasks via a few keystrokes and an experienced user could operate things very quickly. It seems that people have got it in their heads that a mouse is essential and they don't care to think about the best way to drive this highly specialized software. Touch screens maybe (but they have their own problems), but the mouse? - it's a sure sign the developers are clueless.

By MadScientist (not verified) on 05 Oct 2010 #permalink

For a bit of fun context, I recommend "In The Beginning was the Command Line".

Apart from the GAK factor, should you ever need to get into your machine from a distance, there are only two ways to do it: VNC*, and ssh**. VNC attempts to replicate the GUI desktop on your remote machine. Unless you have gobs of bandwidth in your connection, this will basically suck and is for emergencies only. ssh (Secure Shell) OTOH is light and snappy and gives you the standard CLI on your remote machine, as many of them as you want, and you get all the GAK-iness you desire. ssh has other tricks up its sleeve too, enough to warrant its own discussion.

This thread from Greg is quite Linux-oriented. But be aware that you also get cli on Windows in two flavors - horribly broken DOS cli, and moderately OK *nix cli that comes with cygwin. Mac OS X of course is as good as Linux in this respect because it is basically Free BSD, and you can get both the OS X native Terminal and X-windows xterm for your cli delights.

* if you are shackled to a PC you might also have RDP, which is actually slightly faster than VNC because it knows some of the underlying OS short cuts in the display manager.

** along with ssh is telnet. Both give you the same cli, but telnet is open and vulnerable to attack, while ssh encrypts your chats.

By Gray Gaffer (not verified) on 05 Oct 2010 #permalink