Linux Desktop: Command Line vs. User Interface

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More .

In the Linux desktop world, the graphical user interface is here to stay. Old Unix hands may grumble, but the fact remains that, without all the efforts poured into GNOME, KDE, Xfce and others, Linux would not be as successful as it is today.

The reason for the desktop’s success is obvious. A desktop requires much less knowledge than a command line, and is suited to maybe 80% of the most common tasks that an average user needs. If the desktop needs much larger applications, that hardly seems a problem on a modern computer.

All the same, the command line continues to have distinct advantages over the desktop. Although casual users often consider the command line as prehistoric as a giant sloth, it continues to give you more options and more tools that the desktop ever has or is likely to.

In fact, for many administrative tasks, the command line is actually easier than the desktop. Looking through my BASH history, I can see at least five circumstances in which I generally choose the command line over the desktop:

1) File Management
2) Listing Files and Attributes
3) Scheduling events with crontab
4) Package Installation
5) Resources Unavailable on the Desktop
The Best Tools for the Job
RELATED NEWS AND ANALYSIS

1) File Management

Whether you are copying, moving, or deleting files, the BASH shell gives you far more options than KDE’s Dolphin or GNOME’s Nautilus. Such desktop file managers do their best, but they can only plan for the average use cases, and add confirmation dialogs to prevent users from doing something rash.

Moreover, because menu and toolbars rarely have entries for symbolic links, a whole generation of desktop users are unaware that the possibility even exists, or when to use them.

By contrast, consider all the possibilities of a simple command such as cp (copy). To start with, you can decide whether you want an indication of progress, or the ability to confirm before overwriting files. If you want you can archive or backup files. You can choose to create symbolic links instead of copying, and whether to preserve file attributes, and you can ensure that you remain on the same filesystem or not. Other file management commands are similarly versatile, although some of the details differ.

Another practical consideration is that, when moving large numbers of files — for instance, when you are doing a backup — desktops tend to freeze, no matter how much RAM your machine has. Consequently, you can be left waiting for your file management to complete, unable to do anything else. Or, even worse, you can be left uncertain whether you have actually succeeded what you are doing. These problems simply don’t exist at the prompt.

2) Listing Files and Attributes

Just as with the file management commands, the ls command gives you far more versatility than any desktop display. True, by definition you can’t have an icon view, but you can you use colors or symbols to indicate different types of files.

You also have all the filters available in desktop file managers, including whether to show hidden and backup files, as well as the ability to sort listings by extension, file size, time modified, and file version.

However, what I appreciate most about ls is that when you use the -l or -g option, all the information about file attributes is printed on a single line.

By contrast, in the average desktop file manager, you choose the default attributes to display, or at least their order (which, in anything less than a full-sized window, often comes down the same thing). Often, too, permissions are listed on a separate tab, and four or five keystrokes away.

3) Scheduling events with crontab

Some applications simply defy a graphical interface. Oh, you can make one, if you insist, but the result is always proof (if you need any) that slapping everything into a window does not necessarily make for user friendliness.

That is especially true of applications with hundreds of options, such as Apache. However, it can also be true of much smaller utilities such as crontab. I have yet to see a crontag graphical interface that was not more intimidating than the command itself. By the time I have finished deciphering a desktop of crontab, I could have scheduled half a dozen jobs to run at a latter time.

4) Package Installation

Both apt-get and yum, the leading package management tools, have had graphical front ends for years. However, just as with file managers, you can practically hear graphical package tools like Synaptic or the Ubuntu Software Centre grinding away when processing large numbers of files. In fact, when you update, many of these desktop tools simply freeze — often while giving very little indication of what is happening.

Moreover, if you want to install something too soon after you log in, often the graphical tools have a conflict with the update applet. When that happens, you either have to wait or decide which one to close.

Yet, even at their best, desktop package managers have no significant advantages over the command line applications for which they front. The command line applications are among the most straightforward and easiest to learn for routine purpose, and return much more information, especially in .deb-based systems. Aside from the general assumption that users must do everything from the desktop and that the command line should be feared, there is simply no reason not to use the command line tools.

Next Page: Command line and desktop resources….

5) Resources Unavailable on the Desktop

Most of the time, the reasons that the shell is preferable to the desktop are that the available tools are quicker to use and/or have more options. However, in some cases, the reason to use the command line is that you simply have no choice — equivalents are just not available on the desktop.

The problem isn’t that the desktops aren’t trying to fill in the gap. The same is true even on desktops like Windows, which have been desktop-oriented for many years longer than any Linux desktop.

Rather, the limits on desktop tools seem part of the general philosophy of the graphical interface. Desktops are not supposed to support every possible tool. They are designed for general users, not administrators, and only the most basic subset of administrative tools ever find their way on to any desktop in any operating system.

For this reason, the number of command line tools with no desktop equivalency is a long one. It includes NIS, SSH, modprobe, and dozens of others, especially ones that involve setting up, maintaining and using networks, or keeping a system secure.

Personally, I am especially fond of Debian’s dpkg-reconfigure, which provides a text-base interface for reconfiguring major sub-systems, such as video or locale settings. I regret the fact that Ubuntu is deprecating dpkg-reconfigure for several purposes, especially since nothing on the desktop is half as handy.

The Best Tools for the Job

A minority of Linux desktop users prefer the command line in all circumstances. They are proud of their expertise, and seem to consider themselves the natural heirs to Unix, despising the desktop and everything on it.

To me, this position is so nonsensical that it borders on the perverse. Obviously, the desktop is more useful than the command line any time that you are working with a visual display — which is why I have never warmed to LaTeX. I mean, you can use LaTeX for advanced layout if you insist, but why go to the effort when you see what you are doing and save time?

However, a much larger problem today is that many mainstream distributions are determined to ensure that users never venture off the desktop. Certainly, the desktop is good enough for the most common daily tasks, but, when you consider all the latent power awaiting at the command line, not to help users learn the possibilities seems contrary to free software’s goal of empowering the user.

What matters is not whether a command line or desktop interface is used, but what tool is best for the task at hand. In some cases, that tool will be on the desktop. However, in many cases — especially when administration and setup are involved — that tool needs to be typed in at the prompt. Nor is that basic truth likely to change.

ALSO SEE: Seven Current Issues on the Linux Desktop

AND: The Linux Desktop: Nine Myths