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!
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.
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.
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.
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.
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.
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.
Some menu based programs can be made to work with a mouse, some not, but that is not very GAK.
Tom Clancy popout apps are far too infrequent. There needs to be a lot more of them.
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.
- Log in to post comments
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
Your "Tom Clancy" reference reminded me of the Hollywood OS. It's only useful if you're operating at 20 columns. Security is awesome, until you type "Override".
http://ars.userfriendly.org/cartoons/?id=20010111
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.
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.
"and shift-alt-tab to cycle backwards"
With that I impressed my friends who knowed Alt+Tab...
... and then you buy a Thinkpad, and everything is moved somewhere else, because the Ctrl key - your friend for Ctrl-tab - has gone off the usual spot...