Or, The Unix Path to Enlightenment...

There are problems however in attempting to sing the virtues of the Unix way of life. It's all very well citing the old joke of two coders going into a campus cafe and saying "What do you fancy?" "Dunno", replies the other, "something with meat in it, I had something last week that was pretty good, what was it?" and begins to scan the long list of dishes. His friend smiles and says

"Let's see - history 7| grep pepperami"!

GUIs and The Screen of Ignorance!

GUI interfaces hide complexity the user doesn't wish to have to deal with and they can do this very well. They often do this by presenting every choice available for an operation in progressive selection dialogues such as a wizard, or via a multiple selection options screen, and this is seen as good and wholesome and generally a good thing. Or perhaps a series of menus trails across your screen in a never ending cascade of options. This should avoid the embarassing and tedious searches through user manuals and teaches the user to click instead of type as a way to issue commands. However, it has single handledly been responsible for the insidious spread of that anathema to the Old School Way of Doing Things, the utterly evil and reprehensible monolithic interface.

The user learns that if an action is not available to them as a menu option within their all-embracing, ten-thousand-and-one function, 32-megabyte heffalump of a program then there is no way of doing that thing. It is all point and click, point and click. There is neither encouragement nor opportunity for the user to tackle a solution to their work in a creative manner. There is no DIY options screen for the user.

The natural response to this is:

• Command-lines are horrible techie things, where you have to type and are slow and awkward
• (in a scoffing tone) "Oh yeah, try running M$ Office 2000 as a series of command-line parameters..."
• GUIs mean I don't have to think, let alone remember
• What's wrong with a mouse? Clicking's good exercise for the fingers!

Ok, so what is wrong with our beloved electronic rodent? Why all the anti-mouse, anti-GUI claptrap? Dammit, GUIs were a step forward! Well, maybe for some, maybe not for others. You might pause to think a moment why most Unix / Linux users often run 3 or 4 xterm windows during any session, even in this, the post command-line, post GUI world. You might also pause to reflect on the command-line equivilants of Unix in the Windows / MSDOS world. It's probably true that for Windows, any GUI interface is a step forward compared to their command-line environment. But this is not the case with Unix / Linux.

Textual Interfaces - A More Natural Way to Work?

The arguments for GUI interfaces have concentrated on hiding complexity, with the underlying axiom that clicking on a button is easier than typing in a commandline instruction. However, the arguments concerning the way in which experienced users (also known as the charmingly entitled 'power users') tend to ignore the mouse as an interface to their programs are well known. Sometimes scornfully put as 'sheer laziness' or 'poor motor-neuron ability as a result of years of physical inactivity', the truth is that having to take your eyes off where you're working, fumble around for the mouse, concentrate while your gummed up mouse ball slips and jerks the mousecursor past a 4x4 pixel you're trying to click on, is a great deal harder than simply typing Alt+F4 to close a program. Assuming of course, your poor motor-neuron ability doesn't also extend to your keyboard. Mice are slow, keyboards are quick.

Ah, but the pundits say, keyboards are quick only in the context of GUI menu shortcuts. NO GUI, no shortcut. Typing in lengthy commands is slow slow slow!! Well, this is not necessarily so. Take a much vaunted example given by many sys admins. I have a config file, which I need to adjust, run the corresponding process, check the result, close the process, adjust the config file and so on until I have the process doing what I want. I can run the process from the commandline, and I know exactly where in my config file I need to make my changes. Gradually, I begin to build up my commands to reflect my work, pinpointing exactly where in the config file I want to jump to, make my change, and exit. Changing a few letters in a config file and coming back to the commandline to run your process should take no more than 5 seconds. Let's say I'm messing about with my XF86config file (yikes!) and want get my mousewheel and buttons working correctly. To do this, I'm working in the section titled 'Pointer'. Although I'm already working in X (on server :0, the usual default and as usual, I'm running the rather Winbloat-like KDE), I can start up another X server session from the same machine, perhaps running GNOME instead of KDE and switch between them by pressing Ctrl + Alt + F8 and back again with Ctrl + Alt + F7. Ah, two x server sessions on the same machine, such are the joys of Linux! But I digress... as I keep going back to the same place again and again, I can tell vi to jump to that line in the config file each time I call it:

This opens the file and puts my cursor at the beginning of the line containing the word 'Pointer'. I actually only need to alter the protocol from PS/2 to IMPS/2. This I do, press Esc, Shift ZZ and I'm out and back on the command-line. My next call is right there in the history, and starts x with the options I want:

And so on. I can test, make changes, go back and re-test, perhaps each time extending the precision of the command-line switches to customise my working environment to operate and run the tasks I want in just the way I want. You may argue that such an admin type task doesn't exist on windows ('where's that CD with those bloody drivers on?'!), but this example is actually one of many and many of those could involve all sorts of filters and file redirections or pipes. Having to use a GUI editor for such tasks, even if you leave it running just after saving a file change, still means some sort of awkward switch to running your process (and don't all spam me at once, I know you can run shell commands from with vi and emacs). Just getting it started involves time and resources as all those pretty widgets are dredged up into your machine's RAM. But this is all very well during the course of a session, but what about having to go back and make the changes again in a week's time? How will you remember all those switches and parameters you so carefully built up? Save them in a file? Let the shell do that for you:

will return me a filtered list of my precious commands so that I can run them again (if your shell supports it, type: !n where n is the history number of the command). If you must, you can even highlight them with the mouse (ah ha!) and middle-click them onto the command-line to start again.

Learn to use the wonderfully powerful, highly customizable command-line that comes with nearly every modern shell, and your life and computing experience will be a richer one. One day soon, we hope to have a fuller example of building specific shell script tools to help you with a common task, but until then -

have fun!

Kester Clegg Last modified: Mon Dec 4 23:54:23 GMT 2000