Wednesday, April 6, 2011

From my cold dead hands!

No, this isn't a gun post.  But I feel almost as strongly on this subject as I do about my guns.



Borepatch threw a hand grenade into the hen house in his recent post about how the Command Line Interface (CLI) on computers was going the way of the dodo in favor of Graphical User Interfaces (GUI).  For you people who work in the real world, Microsoft Windows is a GUI.  You see a menu or a set of buttons, you select what you want the computer to do with the mouse or some other pointy-clicky device, and the computer does what the program tells it to do.  When you open the C: prompt, now called the Command Prompt, on your Windows computer, that is a CLI.

 I can see his point from the end user perspective.  Although in my day job, we still use a lot of CLI type applications on *nix, mainframe, and even some Micro$oft systems, even if they're encapsulated within a Windows interface.  But on the whole, most non-tech people who use computers will almost never open a command line unless they're on the phone with tech support.  So, Borepatch's assertion is correct for most consumers.

However, for those of us who work with computers, as opposed to those who use computers to do their jobs, the CLI is our bread and butter. Even the Windows guys I work with eventually migrate from GUI-only perspectives to using the command shells on their systems for at least some of their work.

GUI's, even for some admin work, are great for beginners who are following a script to accomplish a set of discreet tasks or to do something that should be simple but isn't if done the old fashioned way.  I've been known to use a GUI to set up printer queues and such on my systems from time to time simply because the CLI way of doing it is arcane and easily messed up.  But using a GUI exclusively can give someone a false sense of security when it comes to working on a system.  Yes, you can set up almost anything on a Windows system and a  lot of things on a *nix box with graphical interfaces, but you may not know what to do when the GUI doesn't do what you tell it to do.  Troubleshooting through a GUI, if it's even written into the application, can be ugly.  If you have access to C:, #, or $ (Cthulhu forbid SYS$SYSTEM) you can quickly look through logs, enter diagnostic commands, and try different solutions that may or may not have been included in a GUI.  Knowing what goes on behind the buttons comes from doing these tasks on the CLI, and being able to troubleshoot when things go wrong is crucial.

And for those of us who take care of more than a couple systems, using the CLI to remotely administer them makes life a heck of a lot easier and more efficient.  It takes a heck of a lot less bandwidth to send CLI commands to a system at the end of a 56k modem line (don't laugh, I do it all the time) than it would be to get GUI commands and output from a remote graphical service down the same pipe.  Even Microsoft appears to be remembering that not everyone has fat pipes to all of their systems, and has built a remote, secure CLI into Windows Server 2008.

Maybe I'm just showing my age here, but it will be a cold day in Cuba before I stop using CLI on my systems, and something tells me that CLI in some form will be used on computers long after I hang up my SSH keys.

2 comments:

Borepatch said...

I actually like the command line, and still toss together the odd C-Shell script now and then (yeah, I'm a geezer).

I was being a bit tongue in cheek about the kids over at Slashdot, but boy howdy, I guess I kicked over the ant hill!

DaddyBear said...

I'm no spring chicken myself. Yeah, this is the computer equivalent of Glock vs. 1911.

Oddly enough, writing scripts and such is one of the few things that I prefer to do in a graphical editor such as xedit or the Gnome Text Editor. I fall into the vi camp, but anything more than a few lines and I'll drop back to something a little easier to use.

Creative Commons License
DaddyBear's Den by DaddyBear is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.
Based on a work at daddybearden.blogspot.com.