This is the second part of a series of posts on the Power of the Command Line. (The first post was: The Command Line in Linux, Mac OSX and Windows)

The lesson of today’s post is: Don’t be a chump, learn to love the command line!

Let’s say you have a folder full of images you just downloaded from your camera, but they are all full sized and uncompressed jpegs. You want every image to be a maximum of 640 pixels wide and 50% compressed jpegs so you can send them to your grandmother. There are 1,112 images. Well, copy them into their own directory, Open the command line, move to this directory, and type:

mogrify -resize 640 -quality 50 *

You are done. What could possibly be easier than using the command line?

One of my favorite day to day examples of using a command line applies to killing software. Have you ever been in a situation in Windows where you know some program is still running, with or without some visible trace of it, and you just want it to stop? For “applications” (whatever that means exactly) you can close the application using the task manager, just a few clicks away. But if the thing that is running is a “process,” not only is it going to be on a different list which is much longer and harder to find things on, but it will be given some esoteric name that you don’t recognize. And then, when you try to kill it the machine might give you crap.

In Linux, you open a terminal, and type in a simple command and the process becomes truly dead. In Linux you have a concept of the command line (even if you only rarely use it) and because Linux programs are all processes (there is not some quirky distinction between things that are “programs” and “not programs” as there seems to be in Windows). So, likely, you know the name of the process you want to kill, and you know how to kill it. Sometimes I just want to close Firefox. I’ve got 15 windows open across four desktops. I could go find every one and click on the little ‘x’ in the upper right hand corner. Or I could find each window and hit alt-F4 to close each window. Or, I can whip out the command line and type…

killall firefox

…. and it is done. In what way is it possible to suggest that this simple, easy to remember and use command, is not scads better than the other mousy-clicky options?

So for many processes, ALL systems have a need for a command prompt, and all three of the systems under consideration do in fact have a command prompt, even if those who feel somehow that having a command prompt is a flaw chose to deny it. When the command prompt is used is partly a matter of strategy, not requirement. If never, ever being required to use the command prompt is the standard for an acceptable operating system, then there are no acceptable operating systems. If there is some magic standard of how often a user needs to use the command prompt before that is acceptable … well, I have two things to say to that assertion. First, that is not fair play. That is a moving target. Don’t give me no stinking moving targets. Second, if you draw the line to include, say, Windows Vista but not Linux running Gnome, then you are probably also drawing the line to exclude Windows XP and all other earlier versions of Windows as being “not acceptable.” Think about that for a second.

Now, moving on to level 5 in our previously introduced framework for computer funcitonality: I find it interesting that scripts can be written in Linux routinely, and that scripts are actually expected in Linux, while in Windows, to run scripts you first have to install a special system the emulates Linux. But, the average user does not care about this and in fact will recoil at the idea, and will never really do it. (I don’t count Visual Basic as a scripting language, but you can if you wan to. Good luck with that.)

However, if you are an average user, there are things for you to consider.

For example, think of the tech support people upon whom you sometimes rely. Even though Linux is a much more powerful and adaptable system than, say, Windows (I know, that statement will cause a fight, but bring it on!) it is actually easier to obtain a high level of expertise with Linux than it is with Windows, and once that expertise is obtained, it is easier to figure out what is going on in a Linux system than in a Windows system. There is a simple way to prove this. Watch a bunch of broken (software-wise) Linux computers get fixed, and watch a bunch of Windows computers get fixed. Then, compare the following numbers:

i) The relative frequency of “wipe and reinstall” procedures that ultimately were implemented to fix the system. The answer will be: In Windows, this is routine, in Linux, this is not done; and

ii) The relative frequency with which the “expert” once given a shot of truth serum, says “Oh, it just started working, and I’m not exactly sure which thing I did made that happen” vs. “I did this, and here’s the text based configuration file for some part of your system before and after so you can see what I did and do it again if you have to.” With Windows, it is routine to “fix” something and have no idea what really happened. In Linux, that happens some times but usually there is an explanation for what happened, it is easier to figure out, and it can be replicated. When one “fixes” a Windows system, one obtains an elevated sense of magical power. When one “fixes” a Linux system, one learns something new.

Putting it another way: Consider two kinds of cars, A and B. For Car A, you know that almost all mechanics can easily fix it. For Car B you know that fewer than half of the mechanics can fix it but will try messing with it anyway, and if they break it they’ll just tell you to get a new car. Remember: This hypothetical difference is intrinsic to the cars, not the mechanics. So, which car are you going to by, all else being equal?

Another issue for “regular” (non-expert) users is this: There may come a time when you would like to automate, or in some other way fiddle, with your work flow. If you are a photographer and you regularly do certain processes to download, alter, back up, resize, etc. your pictures from the digital cameras you use, you might find out that a few hours a week (which will add up over the year) can be saved by having these steps automated, and it might be worth hiring someone to do that for you. If you do such automation in Linux, it will be cheap and it will work well. If you do this in Windows … well, good luck with that.

Comments

  1. #1 travc
    August 11, 2009

    I can’t believe this hasn’t been linked yet:
    In the Beginning was the Command Line by Neal Stephenson.

    As for install problems and other typical complaints… that is a function of market share more than anything else. Writing good installers, drivers, and managing software dependencies under Linux is generally immensely easier than Windows. There are certainly issues with some Linux installs (especially on bleeding-edge or odd hardware), and the fix is normally some command line voodoo. The fix for such issues under Windows is normally “don’t use it”.
    Apple restricts their hardware and has a smaller program base, so they mostly just avoid these issues.

    Lets put it very simply, there are different sorts of users. Even the most super polished GUI is not good for someone who really uses the programability of their computer. Many people use computers as more passive tools, and a GUI is most often easier… assuming the GUI writers predicted exactly what you want to do.

    Users who want to use a computer to run some particular programs to perform specific tasks generally fear the command line. Users who want to use a computer to automate tasks and/or develop new methods to solve problems really need the command line.

    Also, have you ever tried to explain how to do a moderately complex series of GUI operations over the phone or email? When I have to help out my more computer challenged colleagues, I often just write a script and send it to them.

    PS: A lot of CS folks use OSX. The GUI is quite nice and the command line (and porting and emulation) make it pretty useful. However, Apple does a horrible job actually providing documentation for the things they do differently from other *nix distributions… so the learning curve ends up being a step function to get to ‘expert’ level. Not much of a problem for CS types who enjoy figuring out that sort of stuff, but a pain for more results oriented types.

  2. #2 Hanspeter
    August 11, 2009

    @travc: OS X is decently well documented. Pointing out all the differences between it and Linux would take an entire CD. OS X is not Linux; it is Darwin, which is an offshoot of BSD. Just because Linux and BSD do some things similar doesn’t mean they should do all things the same way.

    The biggest issue is OS X does not use many (any?) of the GNU tools, which frequently are named the same as the original unix tools on which they are based. And so, GNU ‘find’ decided to invent ‘-xtype’, but POSIX ‘find’ knows of no such thing and fails accordingly. Frankly, this is a problem with GNU for calling things that work one way the same thing as another tool with a different behavior.

  3. #3 Greg Laden
    August 11, 2009

    Just because Linux and BSD do some things similar doesn’t mean they should do all things the same way.

    At the level of the present discussion, across these diverse operating systems, it would be counterproductive to put BSD in and Linux in different categories.

    For GNU on OSX: http://www.osxgnu.org/

  4. #4 JJ
    August 11, 2009

    RE: Processes In Windows
    One thing to note, is that often times processes are actually being ran by a service. If one kills a process, either from the command line or task manger, and it is being ran by a service, the service may in fact re-launch the executable. What one can do is kill the service to kill the process, either from within the MMC or from the command line, using net stop servicename. As you mentioned, sometimes these service names can be a bit cryptic, but a bit of digging around can be quite helpful.

    The command line is the IT techs most valubale tool, regardless of OS. Through the command console there are things you cannot do any other way within Windows server. In fact, I have a 392 page book dedicated to the windows command line on my desk, right now.

  5. #5 Alcari
    August 11, 2009

    It’s a bit unfair to confuse the usefullness of the morgify command/feature with the usefullness of the commandline. If the mogrify command didn’t exist, the commandline wouldn’t do you any good. Similarly, if it was a seperate program without commandline function, it wouldn’t do you any good either.

    I think the usefullness of the commandline lies mostly in not having to dig through endless tables to be able to do something you know needs to be done, just type it in. It’s like the ultimate assistant, just shout what you need done and it does it, saving you all the time to dig through tonnes of work.

    I do have a few problem with the post though.

    “With Windows, it is routine to “fix” something and have no idea what really happened.”

    Really? I’ve never noticed this. I wonder if you’re comparing the work of Linux experts with Windows laymen. I’ve personally only ever had this once with Windows, in a long history of playing repairguy for the extended family.

    I think it’s because you can handle a problem in three ways.
    1 – Diagnose and solve right away.
    2 – Be stumped and give up.
    3 – Guess and try untill you solve it.

    My guess is that option 3 happens a lot less frequently on Linux systems, both because of the people that use Linux and because it’s not as easy to do as in Window/MacOS.

    “When one “fixes” a Windows system, one obtains an elevated sense of magical power. When one “fixes” a Linux system, one learns something new.”

    Nonsense. There’s absolutely no difference between messing around with commands to find a solution and messing around with buttons and checkboxes. If you don’t know what you’re talking about, you won’t learn a thing, except for another button on your blackbox. The net result is the same, wether you learn that “ObscureRunMode has to be set to TRUE” or “‘Use Obscure Running method’ should be enabled”.

    Wether you find the solution by messing with stuff untill it works, from a forum or from a manual, if you don’t know why something went wrong and why it’s working now, you stay at the level of “push button, get cookie”. The choice of OS makes no difference.

  6. #6 Alcari
    August 11, 2009

    Hmmm, pretend I didn’t make all those typos. Posting at 1 AM makes me post the non-spellchecked version….

  7. #7 D. C. Sessions
    August 11, 2009

    Greg, I’m a bit surprised that you don’t analyze the command-line/GUI contrast from an anthropological perspective.

    After all, we-the-species had “point and grunt” communication for the majority of our existence as a species. Language appears to be a relatively recent development (IIRC about 50 KY.) That development was so powerful that it swept (again, IIRC) away all of the other early humans who didn’t get with the new technology.

    Language is power — it has a concise expressiveness that other communication methods can’t touch. The command line is language — if you want concise expression, you use it. If you want a social experience with minimal content, by all means point and grunt.

  8. #8 travc
    August 11, 2009

    @Hanspeter, you are of course correct that BSD != Linux. I have nothing against BSD, though I’m less familiar with it and do get caught by differences occasionally. I was actually referring more to stuff like netinfo.
    Greg is also right that for this discussion the difference between two good command lines (BSD and Linux) isn’t really relevant.

    Maybe more relevant, Apple provides are very well designed GUI atop a more or less standard powerful command line. They do fall down occasionally by implementing things in a too GUI reliant way (operations which are available in the GUI but very difficult on the command line)… Sometimes they seem to view the command line as just a backend for the GUI and design command line tools which aren’t really meant to be used ‘by hand’.

    That is a failing which good general computer systems should avoid. Yeah, most users try to avoid the command line, but there is no good reason that a system shouldn’t have both a nice GUI and a powerful command line. When marketing people ‘design’ a system, they very often don’t even consider command line functionality. Programmers will almost always end up including a decent command line anyway, since it makes their lives much easier… However, it won’t be very carefully designed for usability. Windows is the poster-boy for this effect in my mind, though MacOS was worse in that respect I suppose.

    Anyways, “the right tool for the job” is probably the relevant axiom. Users shouldn’t fear the command line. Sometimes it is more appropriate than a GUI interface. Even if you don’t routinely need it, don’t forget that actually opening up a terminal and issuing command line commands is a perfectly reasonable option. You can even write commands into a simple to script to create your own automation without much difficulty. The learning curve is initially a bit steep compared with a GUI, but it quickly levels off to a nice gradual slope reaching high into the clouds.

  9. #9 MadScientist
    August 11, 2009

    “I want a GUI!” Well, very many services have a WEB interface so people should stop whining about not having the GUI.

    A GUI for *all* the *NIX tools? Hahahahaha! There are *hundreds* of tools, most of which I only invoke maybe once every year or so, while many are invoked by any of the numerous system setup scripts. One GUI for ‘nl’, one for ‘df’ – naah. Maybe some file browser people might build in those options, but you’ll still have a file browser with a ridiculously complex menu to work through. Besides, the majority of *NIX tools don’t even have an equivalent on MSWinduhs (well, not stock out of Redmond at any rate; you can install the GNU tools etc. if you really want to).

  10. #10 Alex
    August 11, 2009

    Alcari @ 5: “”With Windows, it is routine to “fix” something and have no idea what really happened.”

    Really? I’ve never noticed this. I wonder if you’re comparing the work of Linux experts with Windows laymen. I’ve personally only ever had this once with Windows, in a long history of playing repairguy for the extended family.”

    My experience of this is more like Greg’s, often when I’ve fixed a Windows error I have had little or no idea what I did to change it, whereas in Linux I usually have some idea of the error. I agree that the problem solving approach is probably partly to do with this, but I also think that the openness of the OS has something to do with it. In Linux it seems easier to get the computer to tell you what is going on, while under Windows you need to jump through more hoops.

  11. #11 Heraclides
    August 12, 2009

    travec: Sometimes they seem to view the command line as just a backend for the GUI and design command line tools which aren’t really meant to be used ‘by hand’.

    My own impression is that Apple is primarily using BSD as a powerful “core” upon which they can place their GUI. The fact that it can be used directly is really a nice bonus to them not their main goal (after all command-line users will be a minority of their market).

    Regards OS X documentation, I have to admit I wish O’Reilly had kept the Mac OS X in a Nutshell” series going, as it pooled everything at a reference level. For those who might be interested in it, Mac OS X For Unix Geeks (O’Reilly) is supposed to target the difference between OS X and the “traditional” Unixes (I have haven’t read it, so I can’t say how well it does this or not).

    FWIW, you can kill applications/processes several ways in OS X via the GUI (e.g. via the pop-up menus in Dock and via Activity Monitor) and also via the command line, so at least for that example you can have it either way! It’s a bit saner to do it from the GUI, unless you already happen to been using the command line and you know the PID, etc. of the top process.

    Just for fun: I vaguely recall an OS X application that would take a unix command and a description of it’s arguments and generate a little GUI application for it. I’m not saying I recommend, but I thought I’d toss this in for amusement…

  12. #12 Heraclides
    August 12, 2009

    Oh, rats. The first part is for travec. The rest is general comments. I’m not meaning to telling an experienced OS X user what they already know!

  13. #13 Jeff Knapp
    August 12, 2009

    I would just like to clear one thing up.

    I have never claimed that an OS having a command line is a flaw. It most certainly is not. Those who know the syntax and like to make use of it do indeed get many chores done very efficiently. That is great for those who like to work that way. I, for one, cannot stand it. My mind simply does not work that way (I am mildly autistic with mild, dyslexic-like features – it is a real issue for me.)

    That an OS requires the use of a command line to get things done, that is a flaw – at least if you intend that OS to be a consumer level OS. If you intend it for engineers and programmers, then no problem of course.

    From what I have seen so far, that appears to be the case with Linux – maybe not very often and not for most routine tasks but, dependency is still there. Eliminate the need for the command line by the average user then, you have an average user ready OS. OS X is there, Windows thinks it is there but is not, Linux as mostly there but still needs work.

    Then there is whole discussion of GUI design and how well it works or doesn’t but, that is a whole other discussion.

  14. #14 Jeff Knapp
    August 12, 2009

    mogrify -resize 640 -quality 50 *

    You are right Greg, this is a very easy and simple command and it would easily process that 1100 some-odd pile of images if you know the lingo and syntax necessary to compose such a command. Frankly, this is not my idea of a good time on a computer.

    For me, using Apple’s “Aperture” to open a folder of photos, select them, invoke a command from a menu to resize and then same them out as JPEGs at 50% is much easier. No knowledge of syntax or lingo is needed, no memorization of same said necessary. I don’t even really have to know much of anything ahead of time to accomplish this task. If I had to know how to compose that command in order to get the job done, I would be lost.

    Saying to someone who does not know the lingo and syntax of a given OS command line to just hunker down and learn it is the equivalent of asking someone to learn a whole new language in order to be able to use their computer. I certainly do not want to have to do that.

    Bottom line:
    Command line as an option – great!
    Command line as a requirement – forget it!

    That is the last I will say on this subject. I think I have made my argument clear.

  15. #15 Greg Laden
    August 12, 2009

    Jeff: I’m certainly not asking people to learn stuff they don’t want to learn. Read what I’ve written! People are more than welcome to use the GUI, or the command line, and both are powerful tools.

    The point I’m making is that people are judging the different operating systems by whether or not there is required command line use, or much command line use. I’m saying that most of what people say about this issue is incorrect, and that it is a poor way to judge an operating system.

    Regarding your bottom line: The command line is required in all operating systems, and it is an option in all operating systems. So, your bottom line should be that all operating systems suck, and all operating systems are great.

  16. #16 Hanspeter
    August 12, 2009

    (this was written yesterday afternoon as part of a longer response, but I never sent it and the other parts are not relevant anymore)

    GNU/Linux has become synonymous with *nix for many people and yet that comparison fails when the discussion talks about *nix but uses Linux specific examples. Your earlier example of ‘cat foo.au > /dev/audio’ will fail on OS X because it does not have /dev/audio (I think on IRIX as well, but I can’t verify that anymore).

    If you say “‘unix’ tool foo will do this” will pretty safely apply to Linux, but “linux tool bar will do this” has a non-trivial chance of failing when done on other unix-like systems (using their native version of the tool, not a ported one).

    ps. for GUI frontends for command line tools, Kaptain is a great tool. Making the GUI is not automatic, but not difficult.

  17. #17 Ray Ingles
    August 12, 2009

    Jeff Knapp – I went to map a drive yesterday from a windows box. I brought up Explorer, put “\\server\sharename” into the address bar… and it just sat there. So I used the menu to fire up “Map Network Drive”, put in the same thing… and got “Drive is already mapped, you must disconnect” or some such.

    But it didn’t show up in Explorer. WTF? I got some advice from a colleague, fired up the command line, ran “net use”, and saw the share listed, but with no drive letter. I had to run “net use /d [sharename]” to disconnect it. After that, I could use the GUI to map the drive.

    If there was a GUI way to do it, I’d love to hear it…

  18. #18 Greg Laden
    August 12, 2009

    “With Windows, it is routine to “fix” something and have no idea what really happened.”

    Really? I’ve never noticed this. I wonder if you’re comparing the work of Linux experts with Windows laymen.

    It happens all the time. All the time. Not coutning all the times that it happens, it ALSO happens almost very tome the solution is “wipe the hard drives and reinstall the sytem.”

  19. #19 Greg Laden
    August 12, 2009

    I just installed a network printer on my LAN at home. To make the Linux computer recognize it I entered one command, got a quasi-gui (character based) menu driving thingie that asked me five questions, the answer to each question being “default” and I have a printer.

    My windes machine is still trying to find the scanner I unplugged and threw away because i needed space for the printer. It is possible that my windows machine will never find this printer. No problem really beause I never use the windows machinee for anyting important (it is jsut an elaborate charger for the ipods, really).

  20. #20 Jeff Knapp
    August 12, 2009

    @Greg:

    Regarding your bottom line: The command line is required in all operating systems, and it is an option in all operating systems. So, your bottom line should be that all operating systems suck, and all operating systems are great.

    This is where I think you are wrong. I have never once had to use the command line in OS X to use, install, or upgrade my system or any of the software or hardware installed in it. I have experimented with it here and there but, that is a different story.

  21. #21 Greg Laden
    August 12, 2009

    Jeff: You really are not paying close attention here, are you!!???

    It is quite possible to install Linux on a computer, and use it nicely for a long time and not use the command line ever. That is one point.

    The fact that some installations require the command line is remarkable. Remarkbable beause those instalations are even possible. There is not a single desktop computer in use today or any time over the last several years on which Linux cannot be installed. Mac OSX, on the other hand, only installs on a tiny percentage of systems. That makes the comparison of how well installations go utterly absurd. Utterly.

    Having said that, if you pick your hardware with reasonable care (and it it not too hard to do this) than Linux CAN BE and often IS command-line free.

    However, to fetishize the absence/presence of the command line is … Oh, christ, just go back and read the posts, man!!!

    BTW I’m typing this on a laptop runing Lunix. No command line has even been needed here. I ressuructed an old computer that I use as a server and for specialized hardware. No command line has ever been run on that computer. I have another computer which has multiple hard d rives, is connected to three printers and two scanners, has two monitors, and which I use for all my photos and for all kinds of other stuff. In a former incarnation I needed the commmand line and to mess with config files to make the two monitors worked. When I upgraded to Debian 8.x something Linux, with Ubuntu, the dual monitor configuration was a GUI. I did not need the command line for anything.

    Didn’t need it, but I use it because I like it. So don’t give me “I have a mac and I just click on it and it works.”

    BTW, we also have a 9 year old HP laptop and a 7 year old Titanium running Linux, no command line used, everything works fine. A Titanium, by the way, that will not run the current version of OSX. Titanium is an Apple computer. Won’t run the current apple system. Case closed, man.

  22. #22 Jeff Knapp
    August 13, 2009

    Wow. If that is true, then I stand corrected – completely. If true, then it would seem Ubuntu really can stand its ground against OS X. That would be awesome.

    Having said that, if you pick your hardware with reasonable care (and it it not too hard to do this) than Linux CAN BE and often IS command-line free.

    IF, and this is a big IF – IF you know what you are doing. If not, then one would need a great deal of hand-holding or, pre-built systems with it already installed.

    Who sells pre-built systems with Ubuntu/Linux pre-installed and configured?

    or

    Where does one find information on what hardware to pick? If I wanted to build a system with eight cores (2 x Quad-Core Intel Xeon), 16 gig RAM, four 1.5 TB drives, a kickass graphics card, an HD video I/O card (AJA, Matrox, or Kona for example), Firewire 800, eSATA/SATA interface, a professional audio interface (multi-channel I/O with 7.1 surround monitoring), two HD monitors, and be able to have a hassle-free install of Ubuntu on it – where would I look for such information? (This is equivalent to my Mac based system now.)

    Mac OSX, on the other hand, only installs on a tiny percentage of systems. That makes the comparison of how well installations go utterly absurd. Utterly.

    That is because of the EFI boot firmware. That asside, it is for very good reasons – it is part of what makes it as good as it is. However, I am not just talking about installing the OS itself, I am also talking about installing third-party and after-market products. The system I described above was one I put together myself from a bare-bones stock Mac Pro. (Apple does grossly overcharge for all of the add-ons such as RAM and HDs.) The installation of all of the components and software packages was typically smooth and hassle-free – what I have come to expect over the years with the Mac OS environment. One thing is true – I would love to be able to cobble together my own Macs if I could.

    How trouble-free is this kind of thing generally with Linux based systems? Base on what you are saying, it seems it might be close (depending on the product of course).

    My claims of “it just works on a Mac” are correct the vast majority of the time due in large part to this tightly controlled ecosystem. That is why I use the Mac and have used it for the past 25+ years. Even in the pre OS X days, as far as true “plug-and-play” goes, the Mac OS always has had it all over Windows.

    So, what will it take (assuming Ubuntu/Linux really has matured to the level you are stating) to get commercial developers to start supporting it?

  23. #23 Heraclides
    August 13, 2009

    Greg,

    You wrote: Regarding your bottom line: The command line is required in all operating systems, and it is an option in all operating systems. So, your bottom line should be that all operating systems suck, and all operating systems are great.

    Best as I recall, “classic” Mac OS 7, 8, & 9 didn’t have any command line (or at least one that was accessible to end users), so I’m not sure that “The command line is required in all operating systems” is really true. I can’t see why it has to be the case for an OS either from the point of view of OS design, either. (I can see why most people choose to, of course.)

    The command-line for many people is just a nice option for those who prefer to work that way, but it’s not necessary. One of the reasons many people don’t like the command line is that it forces rote learning. Good GUIs lead you to the tools, as it were. (Yes, some things are more easily done via a command-line, but my feeling that’s not because “the command-line is inherently better”, but simply because no-one has written a (decent) GUI counterpart.)

  24. #24 CraigF
    August 19, 2011

    “Best as I recall, “classic” Mac OS 7, 8, & 9 didn’t have any command line”

    You’re wrong there. The programmer’s switch on old Macs brought up a basic command line. This was intended for debugging hardware and software.

Current ye@r *