I've always been comfortable using the command line interface to get specific tasks done. To me, the command line was a necessary tool as well as a last resort -- if all else failed, I knew I could count on a command line program to fix the problem. I already knew that I could do pretty much anything from the command line if I was willing to sit down, read manual pages, and learn -- or if I really had to. To prove it, recently I forced myself to use only the CLI for a week. I ended up learning a lot more than just a few command line arguments.

I decided to use OpenBSD 3.5 on my Dell Inspiron 3800 latptop for this exercise instead of Debian, Slackware, or Gentoo Linux because, in addition to knowing that OpenBSD worked perfectly on the laptop's hardware, I wanted to use this opportunity to get to know OpenBSD a little better. Also, OpenBSD has a feature that I thought would make my week easier: the Ports software database. Ports makes it easy to find and install programs from the command line -- easier for me than Debian's APT or Gentoo's Portage systems. I didn't know what programs I'd be using, so it was important to have a decent selection of mail, IRC, and other programs to choose from. OpenBSD's Ports tree, while nowhere near as extensive as FreeBSD's, was more than adequate; one could even say that it was designed with CLI use in mind.

I had the advantage of working with people who primarily use the CLI for everything they do. I asked them for some recommendations and occasionally for some help, but I didn't ask to be walked through the whole experience -- that would invalidate the exercise.

Software

The one program that I needed right off the bat was a competent FTP client. I was used to using the graphical gFTP, which is about as good as they come in the world of X11, so whatever I ended up with in the CLI had a lot to live up to. The standard BSD FTP program that's included in nearly every operating system is great for transferring single files, but it's horrible for uploading or downloading large groups of files. Brian Jones, author of Linux.com's SysAdmin to SysAdmin column, turned me on to NcFTP, which I found to be an excellent alternative to the old BSD FTP. Configuration was pretty simple, and I was able to upload and download multiple files in a queue and save bookmarks to oft-used FTP sites.

Much like the FTP situation, I knew I could use the standard interface to ircii if absolutely necessary, but I'd prefer something more like the excellent XChat2 graphical IRC client. I tried Epic, but found it to be rather unremarkable. Digging deeper into Epic's configuration docs, I discovered that there are many pre-made configuration scripts for it. After looking at several of them, I settled on DarkStar; while it wasn't everything that I wanted, it worked better than what I'd had previously. I used Epic and DarkStar for the first two work days of my week in the CLI.

The biggest challenge I had was with email. I was used to Evolution, which runs my personal and business contacts, calendar, and email. I didn't mess with calendar or contacts programs because I didn't think I'd need them for the week, but I did explore text-based email programs.

BSD Mail comes standard with OpenBSD, but its operation and configuration were a mystery. I could read local email, but I ran into difficulty trying to configure it to receive POP3 mail. Even if I'd gotten it to work perfectly I'd have to take notes on all of the shortcut keys because there are no on-screen helper menus; you're left at a prompt with a list of messages. I wasn't against learning how to use it, but with so many other programs to have to remember key commands for, it seemed like a better idea to simply try a different email client.

I set up Mutt to receive POP3 email from one of my accounts; I have eight POP3 email accounts that I need to collect all in one inbox. The Mutt configuration file is gigantic; there are so many settings that it took an hour just to read through each option and its description. The manual page is equally gargantuan. It's nice to have a lot of features, but if I have to crawl through pages and pages of options that I'll never use just so I can learn how to do the simplest of tasks, I can safely declare the program useless to me.

I tried Pine, but that was just the opposite of Mutt -- the interface was so simple that I couldn't figure out how to get multiple accounts into it. I could hardly configure it for one account, even after reading the instructions.

The trouble with the email programs that I tried is that they are designed primarily for two kinds of people: those with one email account who need a bonanza of options that deal with mailing lists, and those who are concerned only with local system or LAN mail. In other words, they were made for developers and sysadmins.

I was considering giving up, but a friend suggested that I install Fetchmail and use it to send all of my POP3 email to my local username. That's exactly what I did, and it was a lot easier than I thought it would be. Reading the Fetchmail manual page was less daunting a task than I'd anticipated, and I had Fetchmail retrieving all of my POP3 mail inside of an hour. I created a config file that would regularly retrieve mail from all eight accounts and then pass it all on to my local user account. This cut out all configuration difficulties that I'd had with my email programs because all three could receive local mail by default. Mutt didn't seem so useless to me after that. My only complaints about Fetchmail are that I never figured out how to set it to leave all mail on the server unless it had already been downloaded, and I couldn't get it to delete mail from the server that I deleted locally. I like to save all non-spam email as a reference.

The vi editor comes standard with pretty much every Unix, BSD, and GNU/Linux operating system. If you know how to use it, it's a powerful and convenient editor to have; if you don't know how to use it, it's an archaic, non-intuitive piece of garbage. My previous opinion of vi tended toward the latter, but I figured that now was the time to learn how to use it properly. Instead of vi, I installed vim from Ports because I wanted to take advantage of its syntax highlighting and automatic indent features, among other various improvements. The first thing I did was to run the vim tutorial to learn vim's finer points. I got most of the way through it before I learned everything I needed to know to work on HTML documents and configuration files. Since I already know how to insert, delete, save, and quit, the supplementary commands that I learned were easy to remember. Of all of the programs I used in my week in the CLI, I spent the most effort learning to better use vim. I considered using Emacs -- in fact it was my first choice, because I knew slightly more about it than I did about vi, but I couldn't get a non-X version installed through Ports. Emacs is also not quite as universal as vi is, and I wanted my learning to apply to as many systems as possible.

I'd heard of GNU Screen, but I didn't think I'd ever need to use it. I couldn't imagine needing more virtual terminals than what were provided by default. On the other hand, I didn't anticipate working from the command line full-time, and it didn't take me long to figure out that it was worth the effort to install and learn Screen. I was amazed at how easy it was -- all I needed to know was how to start Screen, how to open new terminals within it, and how to switch between them. It took five minutes to read through the help file, and soon afterward I had my IRC client and Mutt running in TTY1, two instances of vim open in TTY2, and four or five instances of Lynx open in TTY3. TTY4 was for other command line tasks, should they become necessary. This remained my preferred configuration for the rest of the week.

I used Lynx as my browser; I don't really like Lynx, but what else is there? By the time I got to learning Lynx, I was struggling to remember all of the command keys for all of the programs I'd installed. I was so disgusted by the fact that the Web was no longer graphical that I avoided Web activities as much as possible.

Lastly, I used cplay to play Ogg and MP3 files while I worked. It's the one program that I didn't need to read the documentation for, and it didn't need a mile-long config file either.

Putting it all into production

I spent the weekend setting all of this up, experimenting with alternative programs, and messing with config files. I didn't make a whole lot of progress before Monday, and needless to say I didn't get much work done at first. Well, actually, I didn't get much work done all week because of the snags I ran into.

The most difficult part about using the CLI for production desktop work is using the Web. To me, the World Wide Web was made to be a graphical experience, and it should always be that way. Once you've gotten used to Mozilla, you can't really switch to Lynx and enjoy it. Lynx is purely for the retrieval of necessary information -- you use it when you really need to read something (like documentation) on the Web and you can't get to X. My colleague David "cdlu" Graham tipped me off to a console graphics display package called zgv which would allow Lynx to show pictures in Web pages. Unfortunately it doesn't seem to be in OpenBSD's Ports tree, so even if I'd known about it, it would have been difficult or impossible to install.

One trouble I ran into with IRC was the inability to scroll up through a conversation, something that I rely on in XChat2 to get me up to speed. The best I could do is look through the log with the /lastlog command and hope that my search string didn't match more lines than I had screen space. When I mentioned the problem, David Graham gently chastised me for not increasing my screen size from the default (VT100 emulation, which also didn't support color) to something higher. I hadn't even thought about changing the resolution; ever since the dark days before Linux (and Windows) I was used to the standard DOS 80x24 screen and figured that it was just the way things were outside of the GUI.

About the only program I never had any problems with was vim. It always did what I needed it to do, from writing articles (the first half of this article was written in vim from my OpenBSD machine) to creating and editing configuration files. It won't replace Bluefish for my Web work, but it was certainly one of the most important programs for me to have. Sure, vi or the BSD ee editor could have done some or all of the same work, but they wouldn't have been as nice to use. Syntax highlighting is practically a necessity once you're used to using it.

At some point I switched from DarkStar/Epic to irssi, a Perl-based IRC client. while it didn't have the nice auto-notification of incoming email that Epic had, it was easier to use and configure, and it had a number of other features (such as timestamping by default) that I enjoyed. It's not that I couldn't eventually program Epic to do what I wanted it to do; the issue was that I couldn't do it inside of an hour. I don't want to read a 50-page manual and Google my questions for hours just to do a few simple tasks. I'd rather have a program that simply works the way I want it to.

Of all the things I've lost, I miss my mouse the most

It didn't occur to me to use the mouse in the CLI -- as far as I was concerned, the mouse was a tool meant for graphical environments. I didn't use a mouse until Windows 3.0 (except in some DOS games) and I didn't anticipate needing one in a BSD terminal. Since I couldn't scroll any windows with it and couldn't use it to switch between programs, I didn't notice its absence at first.

The trouble was, I needed to copy and paste URLs from Lynx to vim, and there seemed to be no way to do it without highlighting the address with a mouse and then pasting it into another terminal by clicking both mouse buttons. A laptop's built-in touchpad or directional button is not well-suited to this task. I didn't realize how often I used the mouse until it was gone.

Without being able to easily add links to articles, I was unable to complete any of my work. I did write the text portions, adding in href tags where the links would need to go. I then emailed the articles to myself and when I got home, I added the appropriate links in Bluefish. I guess you could say that I cheated, but I had to get some work done.

Keyboard navigation wasn't all that difficult to get used to, especially after I had my GNU Screen setup properly organized. I could switch back and forth between different terminals rapidly, and scroll up and down documents in vim without forgetting to leave or enter insert mode. Although I reached a certain level of proficiency, I don't think that any amount of experience in the CLI could have replaced the convenience of mouse navigation in GNOME.

Home sweet GUI home

While I had fun learning new programs and new tricks, I missed all of the functionality and finesse of GNOME. I don't know whether it's just that the programs I can use in X are easier to configure, use, and multitask, or whether I've lost my love for the command line.

I started out my computing life in the CP/M and MS-DOS command line interfaces, and was dragged kicking and screaming into Windows 95 some years later. At the time I thought of the GUI as a memory-hogging, inconvenient, impossible to configure, buggy, and in general useless layer on top of a simple CLI environment that I knew and enjoyed. Somehow I thought that going back to a more powerful and flexible command line years later would rekindle my desire for a return to the DOS days.

My DOS machine did everything I needed it to do. If I had a new program or game, I knew how to install it and run it, and all configuration was usually done either from within the program itself, or from an external configuration program. There were no config files to hack, and I never once had to read the documentation to figure out how to use a DOS program. In other words, they were designed sensibly, with the user in mind.

Many of the BSD and GNU programs that I used during my week in the CLI, especially all of the mail and IRC programs, almost seemed designed to be archaic and difficult to use by default. I would have found my week more enjoyable with programs that were easier to configure, or at least easier to find relevant information in the manual pages or help files. I have no problem with reading documentation, except when it's dozens of pages long and hides the most critical and basic options and information amid a big steaming pile of superfluities.

Program design -- and of course my own ignorance of such advantages as Linux terminal emulation, higher terminal resolutions, and the zgv terminal graphics viewer -- aside, there's also an underlying roadblock to get past when switching to the CLI: it's a whole different way of thinking. Using a GUI makes you think in a broader, more synthetic, and object-oriented way. It's not just that the programs look prettier and have more convenient mouse-driven features -- it's that you think of your programs and data in terms of how they look on the screen. In the command line you're forced to think in a more analytical way; you have to picture where your data is, where you want it to go, and how you want to view or manipulate it. The GUI tends to make you think in terms of programs and what they can enable you to do with your data; the CLI tends to make you think in terms of data and what you need to do with it. The GUI causes you to ask yourself how something looks, whereas you're using a more kinesthetic sense when working in the CLI. I've come to believe that it is not just a terminal interface, it's a whole different kind of user environment, and it's not for everyone.

Using the CLI for a week seemed to me like a survival retreat in the remote wilderness. It was fun and challenging, but I'm glad to be back home where I can go back to what works best for me. I'll definitely revisit the command line as a user environment, but only at my leisure -- not while I'm supposed to be getting work done. I encourage readers to try this out on their home machine -- if not for a week, then at least for a few days. Hopefully you'll find my experiences and advice to be a good starting point in your own CLI adventures.

Discuss this article or get technical support on our forum.

Copyright 2004 Jem Matzan. Verbatim copying and redistribution of this entire article are permitted without royalty in any medium provided this notice is preserved.