Posted by This is the first in a series of posts on just what the title says: The command line. The main point will be this: Stop worrying about the command line.
Part 1: “If only…”
If you want to clone a hard drive in Linux, all you have to know is that the command dd converts and copies a file, and that in Linux, everything, including your hard drives, is a file. So, you could type:
dd if=/dev/hda of=/dev/hdb
and you’ve got a clone of your hard drive if your hard drive was hda. Of coruse, of hdb existed already it is gone now, so don’t just go typing stuff into your command line.
It is often said that “Linux would be better if you didn’t have to use the command line” or “Linux would be usable on the desktop if you didn’t have to use the command line” or “If only … Linux …. command line … my grandmother …. just click on it…” and so on.
This makes me laugh. I laugh because people who judge an operating system on the basis of whether or not there is a command line do not understand operating systems or command lines.
A command line is a prompt to which one responds with a word followed by between zero and lots of options and data. ls -a in bash produces a list of files, including hidden files. dir produces a similar list in DOS (but the hidden file thing does not apply). Typing something like
cat /usr/demo/SOUND/sounds/cuckoo.au > /dev/audio
in Unix makes a cuckoo clock sound. In OSX, you can use the same commands, plus or minus, as you use in Linux, because OSX is based on a system similar to Linux and thus has a redily accessible ‘shell’ that will run a lot of well known standard commands.
But this command line thing is hard to do. The user has to actually know the commands … potentially many commands to actually do anything … and all the switches and options (like the “-a” in the ls example above). The user may have to type a filename, which may include a lengthy path, exactly. If it is not typed exactly, you get the “else” in the “exactly or else” construct. A graphical user interface gets rid of most of this hardosity by allowing the user to see a word or symbol that triggers a memory. A picture of a 3.5 inch disk (which is an antique hardware item of some kind) is symbolic of the “save a file” command and a picture of a piece of paper with a plus sign may mean “make a new document.” Menus are even more clear and less culturally bound. The standard “file – edit – view – whatever – whatever – help” sequence of main menu headings across the top of the screen, with organized commands and sub menus that fly into view when when you click, allows any semi-experienced computer user to do complex things that only a few years ago required great expertise. And great memory.
Replacing the command line with a GUI means that everything is easier. Microsoft’s operating system (formerly MS-DOS, now Windows) has done this. Apple practically invented this approach. And Linux has a plethora of graphical ‘desktops’ but two that most people chose between, and it’s all menus and icons.
But not all functions on the computer are the same, and not all user requirements are best served in the same way. Think about the things you do on your computer as a spectrum of different types of functions, as follows:
1: The most basic, often low level, system or hardware related functions;
2: Day to day utilities such as file management, desktop configuration, or settings that affect appearance;
3: Running typical applications such as word processor, spreadsheet, graphics programs, and web browsers;
4: Professionalized or specialized use of applications, such as batch processing of images in The Gimp or Adobe Photoshop, or other automated operations; or
5: User engineered “applications” such as complex scripts or specialized software.
This is meant to provide a rough and provisional spectrum of computer use for the present discussion only. Use of this framework in other contexts is not recommended.
At the lowest end [1] we would have the commands you serve up to bash on a Linux or Mac OSX machine or to the “command prompt” in Windows, perhaps to configure some aspect of your hardware that is not really available to you via menus. Levels 2 and 3 are the most common day to day functions, such as copying or backing up files, opening and using text documents or spreadsheets, browsing on the Internet, and so on. These are functions that are designed to use menus in all of the systems under consideration here, and that as far as I know never require the use of the command line in Linux, Windows or OSX.
Level 4 is interesting. If you buy a nice piece of software, you expect it to do nice stuff and to do it effectively and efficiently. Well, it turns out that at some point you might actually expect, even demand, that it allow command line processing. This might be hidden in the guise of a “batch” or “macro” language, but it is a command line capability. If you live in a world in which it is assumed that the command line is always bad, and that a really good system or really good sofware would never saddle you with such a thing, then you have paid extra for a nice bit of irony. At a professional level, you may really want the command line as an option. For example, in Adobe Photoshop you may use macro commands to mass process your zillions of photographs. With this and other batch languages, you may end up with a pseudo-command line that allows you to manipulate the functionality of one program to process a series of files but that does not allow you direct, unmitigated access to any other programs that might have also been integrated into your work flow.
Level 5 is where you decide that none of your other options is good enough so you write a program or a script, or you get someone else to do that for you.
Now, let’s look at how each level compares across the three most commonly used families of system.
The first level of operation, for most normal non-geeked-out computer users, is rarely used but its use is often critical. Many people believe that basic hardware level functionality (and everything else your computer does) requires command line access in Linux, and never involves a command line in Windows or the Mac. This is simply a misconception.
If you need to configure a cable modem for a Windows system you will use software supplied on a CD by the cable Internet vendor. But when something goes wrong and that software simply does not work, and you call technical support, there is a pretty good chance the person on the other end of the phone line is going to have you open a command box and type in stuff. That’s on a Windows system. When that happens, you have to ask yourself, “Could this have been done with menus?” and the answer is, in Windows XP or later, “maybe.” But it is much much easier for the tech to dictate several dozen characters once and have it be done than to navigate you through a GUI that may actually be very complicated and somewhat unpredictable (GUI’s sometimes look very different on different configurations of the ‘same’ system).
It is quite possible to set up a Windows computer and do all sorts of things with it and never, ever, ever type in a command. But what many people do not realize is that it is also quite possible to set up a Linux computer, use it for all sorts of things, and also never have to type in a command. As of this writing, there are probably more junctures where you *need* to use the command line in Linux than in Windows, even though typical desktop users will rarely encounter this juncture in either system. But even more importantly, there are many many cases where you *want* to use the command line in Linux *and* Windows, but in Windows it is either not possible or, perhaps, simply not done, and you won’t find much guidance on how to do it, whereas in Linux (or in some cases OSX), there will be plenty of guidance.
So, at the low end, down near the system and the hardware, command line work is beneficial, critically important when it is done, and for most people rare in any modern desktop computer system. At the high end, it is something we demand despite protestations in other contexts that command line = bad. In the middle, it just never happens. Putting this another way, the basic complaint that Linux will be OK when the command line is no longer used, is obviated by … well, by the reality that a) the same applies to all systems, and b) the command line is not all bad.
So in the end it turns out that you want a command line, and you want it handy, and you want to learn how to use it.
So let’s say you have a complicated PHP or CSS file that specifies a certain color to be used over and over again in your WordPress site. And you want to change the color. You can open the file and mess arond with it, or you could type this at the command line:
sed 's/#FF0000/#0000FF/g' main.css
and go have lunch. Or, check out the next installment in this series: May the force (of the command line) be with you
_________________
Some of the code examples in this series come from this post.
August 10, 2009
August 10, 2009
August 10, 2009
August 10, 2009
August 10, 2009
August 10, 2009
August 10, 2009
August 10, 2009
August 10, 2009
August 10, 2009
August 10, 2009
August 11, 2009
August 11, 2009
(It’s the old anything can be solved with one more level of indirection thing…) As a really good programmer, you’d have thought ahead and done this from the onset, or at least well before a fixed value got spread all over your website code.
August 11, 2009
August 11, 2009
August 11, 2009
August 11, 2009
August 11, 2009
October 22, 2010
, which is now available for the 
