The Command Line - Best Newbie Interface?

An anonymous reader writes "This essay describes the surprising results of a brief trial with a group of new computer users about the relative ease of the command line interface versus the GUIs now omnipresent in computer interfaces. It comes from practical experience I have of teaching computing to complete beginners or newbies as computer power-users often term them."

Brilliant

[jennifer_l]

Wow, what a well-researched and interesting article. Will we be seeing 'newbie conversation' mode with the limited commandset (as used in the article) splashing across the desktop soon? Unlikely, I think, but this article puts the whole thing in a new dimension for me.

I notice the author is multitalented -- he's also the genius behind Desktop Manager [sourceforge.net], a virtual desktops manager for Mac. Wow. If only I was single...

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:4Dos

[muffen]

Remember??

I still today spend way more time in a 4DOS (or well, 4NT) prompt than I do in the windows GUI.
Virtually everything I do at work is done via 4NT BTM files (batchfiles that only work in 4DOS/4NT).

The CMD line interface is really good, and it makes me a little sad that new computerusers don't realize this.
Some things are just done so much quicker using the CMD interface...

For example, I use multiple computers at work, and I have to transfer files between them all the time.. I do this using 4NT BTM's, and it takes a few seconds to transfer a file... doing the same thing in a FTP app takes much longer...

Re:Unix CLI is NOT easy

[BassKnight]

You can configure the shell to work with more confort with the case sensivity issues. Gentoo comes with tcsh preconfigured to behave like that. IMHO i don't find case-sensitiveness an annoying issue, rapid fingers and the blessed tab-autocomplete do the work easy for me.

Re:The 'help' command

[PowerBert]

bash has a help builtin which will direct the user to man and info commands.

$ help foobar
-bash: help: no help topics match `foobar'. Try `help help' or `man -k foobar' or `info foobar'.

Re:Unix CLI is NOT easy

[oingoboingo]

The Unix/*nix/*nux CLI is not easy. It is a major design flaw that the file name "jones.txt" is treated different than "joNes.txt".

This is not true on OS X. The default filesystem is case independent.

Perfect Example - ImageMagick

[Gothmolly]

bash$> for tif in `ls *.tif` ; do convert $tif -border 50 -bordercolor \#FFFFFF -quality 100 -scale 25% -resolution 96 `cat $tif | cut -f1 -d"."`.jpg ; done

Put THAT in your GUI.

Re:Command line is more consistent

[LarsWestergren]

With a GUI, there is a lot of hunting and squinting and guessing: basically, the stuff is never in the same place and never looks the same from one machine to the next.


Well, I like using the command line, but to be fair, there are lots of inconsistencies there too.

* Standards for command parameters. For instance, using a command recursively, sometimes the flag is "-r", sometimes "-R".
* Always use a dash to separate command flags from file names. Except for the exceptions like tar: "tar xzvf filename.tar"
* Differences between unixes and Linux. "df -h" gives you human readable disc sizes in Linux (50G) and an error message in AIX.

Also, while I agree command line commands are more convenient at first, it is easier to remember GUI moves if you have been away for a while. When using an old FTP program I haven't used in years, I can quickly remember the steps I need to take to configure and get started, I hardly need to read the text on the buttons or menues. But when its time to do something on the command line I haven't done in a while, its much harder. "Ok, setting up a new CVS repository. was it 'cvs init', or 'cvs -i' or something else? Do I have to set the CVSROOT environment variable first, or was that just for the clients...?"

The POSIX standard with "--help" "--verbose" and so on makes it easier to use and remember commands, but doesn't solve everything.

Obligatory IBM Model M link

[oneiros27]

The Model M is still being made, under a different name, but you can now get them with a 'windows' key, or even in black.

http://www.pckeyboard.com/customizer.html [pckeyboard.com]

Re:Microsoft demonized the command prompt...

[Big Nemo '60]

...and oddly enough, (a) Microsoft added some sixty (!) command-line functions in Windows Server 2003 and (b) "Longhorn" (ETA most likely 2006 by now) is due to have a *NIX-grade Command Shell (IIRC the codename for development is "monad")

These tools seem mostly geared towards system and network administrators and such. However, looks like they have changed their mind a bit on the matter...

Re:Only for English speaking newbies

[SoTuA]

This way they were much more efficient in a localized GUI.

And how is it different from a localized CLI? Ever hear of a little term called "i18n"?

user@server:~/> cd /root

/root: Permiso denegado.

As for technical terms, that's going to scare somebody who doesn't know it, wether it's in his language or not. ("procesos" is as scary to my mother as "processes").

Re:Command line is your friend

[adept256]

I couldn't agree more. I went without a mouse for two weeks using winXP. Why? Long story! Anyhow, I became so familiar with the keyboard shortcuts, I was soon using the GUI faster than when I was using a mouse.

The keyboard shortcuts are faster (in general) than the mouse-work it would take to do the same thing. There are stumbling blocks, somethings are *impossible* with a keyboard, but on the whole I found a way to do most things. Getting the context-menu from an icon in the system tray isn't as fast as with a mouse, but it's not impossible. Selecting text in IE is impossible, but you can always 'view source' and copy from there.

I still use a mouse of course! They're indispensible, but I'm not as reliant on it. I do shudder when I see someone take as many as 10 mouse-clicks in what can be done in 3 keystrokes. Yes, the keyboard is powerful, and under-rated.

On-topic: I thought the whole idea of GUIs was to make the whole experience more 'user-friendly' for beginners. Maybe in the beginning, but looking around my GUI and it's myriad dispirit elements it's easy to see how a simple 'C:\>' would be a far easier to comprehend starting point for newbies.

Re:CLI vs GUI Ease of Use

[Lussarn]

Your pathnames argument is just wrong. Ever heard of tab completion? GUIs mostly suck because they don't have it. Of course the much critisized GTK+ file selector is one of those that do have it. Learn it and use it, never click again.

Re:CLI vs GUI Ease of Use

[Jorrit]

Never heard of tab completion? All good CLI's that I know allow you to complete a path or filename with a single key (usually tab). That saves a lot of typing. If there are multiple choices for the same set of start tokens then you can get a list of all matches with one key too.

The reason I like CLI's a lot more is that you can use wildcards in them. For example, I often want to move all files that match a certain pattern to some other dir (just an example). This is a lot more clumsy to do in a GUI.

Greetings,

Funny

[Greyfox]

I don't want to know how to operate my car. I just want to get from point A to point B quickly. That would be a much more accurate metaphor for how most non-CS people deal with their computers. And, when you get down to it, how they deal with their cars too.

Re:CLI vs GUI Ease of Use

[CoolToddHunter]

Your whole argument does a poor job telling me why a GUI is better than a CLI. What is does an excellent job at is telling me the differences between the two and the situations in which I would use one or the other, and I really think that is the key.

There are huge differences between the GUI and CLI and they do entirely different things. You use the example of Photoshop or other "applications" that don't really translate well to the CLI. You need the GUI for that. In the CLI, we use "programs" that take care of a specific task and no more. As you say, "fully specified." Great for automation or batch jobs.

I think this is why most people who use *NIX on a personal machine have some sort of desktop on which they can run "applications" and will drop into a shell when they need to run a "program".

Now, which is easier for newbies is obviously up for debate. It's been a long time for me, so I'm really poorly qualified to comment on that.

Re:CLI vs GUI Ease of Use

[ajs318]

Precisely. Try doing the equivalent of this in a GUI;

for i in *wav; do lame -h $i && rm $i; done

You can spend more time fart-arsing around with a drag-and-drool interface than it would have taken you to do it on the command line. That was what I loved about AutoCAD R12 ..... you could type in exact co-ordinates instead of trying to get a pixel-perfect click, and it cared not which method you chose. Ah, happy days. I seem to remember there may have been an AutoCAD for Unix. Anyone ever get it to compile on Linux?

Re:The 'help' command

[OoberMick]

Sounds like bash completion [caliban.org] to me.

And now, everybody read

[bkhl]

In the Beginning was the Command Line, by Neal Stephenson. It's available in text form from http://cryptonomicon.com/beginning.html [cryptonomicon.com].

Re:The 'help' command

[Talez]

For anyone wondering what the hell I'm talking about you can find a web based facsimile of the DOS help application here [vfrazee.com].

Re:CLI vs GUI Ease of Use

[plumby]

With the explorer in WinXP, as you type into the address bar, or Run window, both of which you can launch via keyboard shortcuts, you get a selectable list of available files/directories matching the letters that you've entered.

Re:Perfect Example - ImageMagick

[ScRoNdO]

Well, that would be better:

for image in *.tif; do convert $image -border 50 -bordercolor \#FFFFFF -quality 100 -scale 25% -resolution 96 ${image%.tif}.jpg; done

no need to do `ls *.tif`, and the bash specific construct ${image%.tif} removes a trailing occurence of the word '.tif' from the string $image

Re:Perfect Example - ImageMagick

[JKR]

OK. Open Adobe ImageReady and create a history script of the actions that you want to perform, using a sample image. Note that because it's a GUI application you have immediate visual feedback, and will thus get it right. Now export that script as what Adobe call a "Droplet", setting default options for output file naming, directories etc. Now, using your file explorer, drag and drop the files you want to convert onto the droplet.

Your point, caller?

Jon.

Re:The 'help' command

[Skweetis]

I think you just redesigned bash completion [caliban.org]. This does the "cd a" thing exactly how you want it to. I don't think it handles the argument expansion thing yet though. That would be doable though. Most programs use getopt() to parse arguments, it is probably possible to put hooks into that function that bash could use to do the expansion. It wouldn't be trivial, since you would have to run the program in the background to see what arguments it accepts (probably something similar to how ldd runs a program to determine what libraries it uses), but it could be done.

Re:CLI vs GUI Ease of Use

[TioHoltzman]

You've apparently not used Win2k (this may also apply to Win98 and/or WInXP).
If you use the common open or save dialogs (note that MS Office may or may not use these, I don't recall, but just about every other app out there *does*), you can type the first couple of letters of a file/directory name, and if it's in the directory, a dropdown box will appear, with a list of possible matches that you can use the Up or Down arrows keys to select. Just about as easy as using the tab completion in bash, and you *don't* need to use a mouse at all.

Re:The 'help' command

[Nimey]

With DOS it was easy; everything which was embedded in command.com (thus the necessity to always carry an extra format.exe)

No. Only a subset of the DOS commands were built into command.com. Basic ones like dir, vol, and del. More complex ones (like format.com) were seperate files.

Five years of being a Linux weenie and I still remember almost everything about DOS. Oy.

Re:The 'help' command

[Bitmanhome]

That was great! However, he actually appears with four eyes and a squiggly hair. This looks much better:

PS1="\w \`if [ \$? = 0 ]; then echo :\\\); else echo :\\\(; fi\` "

A very good idea

[Pan T. Hose]

I'd wager that computer literacy amongst people who've tried Linux would be twice what it is today if when you typed help foobar bash would perform a man foobar if 'foobar' wasn't a builtin command. And it'd probably be double that if you incorporated some kind of search facility too. Type in help disk space and get a hit on the df command, for instance.

I think that is a very good idea and for that reason after reading your comment I decided to write such a program according to your specification.

Just remember who has just made Linux four times what it was today: me, Pan T. Hose, PhD.

That having been said, I'll post that program in another comment, because I have to post it as "Code" instead of "HTML." Please mod it up (the actual code, as well as the instructions below) as Score:5, Insightful, so everyone could read it and install, because I think every Slashdotter deserves to have her Linux four times better than it has ever been.

You have to save my program as /usr/local/bin/smarthelp, then run:

chmod a+rx /usr/local/bin/smarthelp

as root and insert this line in your ~/.bashrc file:

[ $PS1 ] && alias help=smarthelp

Remember to give me credit and to not violate the GNU General Public License it is hereby released under. The code follows:

The PTH(R) Smart Help(TM) program - PLEASE MOD UP!

[Pan T. Hose]

#!/bin/bash

# save it as /usr/local/bin/smarthelp
# chmod a+rx /usr/local/bin/smarthelp
# and insert this line in ~/.bashrc:
#
# [ $PS1 ] && alias help=smarthelp

# PTH(R) Smart Help(TM) v1.0.1-pre2
# http://slashdot.org/comments.pl?sid=99801&cid=8510 901
# Copyright (C) 2004 Pan T. Hose, PhD.
# http://slashdot.org/~Pan+T.+Hose
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

a=${@:-help}; help "$a" 2>/dev/null || man "$a" || apropos "$a"

Re:MicroSoft late to GUIs

[Xpilot]

I find the comment "before MicroSoft" amusing. Apple had the first commercially successful GUI in 1984- nine years before MicroSofts wirst usable version of windows. The UNIX world was using XWindows six years earlier too. Everyone was making fun of MicroSoft's lowly MS-DOS interface.

No, no, Microsoft brought about the "dark times" by forcing its braindead "CLI sucks" philosophy on ever single damn computer user.

Re:Recycled FUD

[John Meacham]

Umm. no.
Different people like different things, I have obtained a fair number of linux converts who knew nothing about unix, but saw me typing commands at the computer and wanted to do the same. GUI has in no way 'won', they were never really in competition.

Even better than that would be (no joke!)....

[devphil]

...the help system offered by...

...wait for it...

...VMS.

You type "help [command]" and you entered an interactive mini-CLI environment. The help screens were nested, so your help sessions might look like

help> foo

The FOO command glarbles the gronkulator using the following sequence of steps...

help> examples

Example 1:

foo /wacky /monkey
...

help> Options

The following options are understood by FOO:
...

help> exit

help> gron

The GRONKULATOR command...

help> exit

The help interpreter was "fuzzy", so you could just type part of a command, or even just a topic, and be presented with a list.

Re:CLI vs GUI Ease of Use

[cowbutt]

Poor example. First, the time it takes to start the process means extremely little compared to the time lame will take to do its work.

Yes, but a computer should save me, the user time and effort. In many examples (including this one), once the user has got the basic command line vocabulary and syntax, the command line will be more efficient for the user if they're performing a task at all regularly.

IMHO, about the only times a GUI wins are when you're performing some infrequent operation (such that you need to teach or remind yourself of syntax and options each time) and when you need to perform an operation on a bunch of files for which you can't easily come up with a regular expression. Even then, as your experience of regular expressions grows, it becomes easier to compose more elaborate regular expressions such that the CLI starts to win again in the latter scenario.

Second, if you're performing a command like this, especially one involving 'rm', you want to make damn sure there is no mistake. With GUI it's easier to have such a certainty.

It sounds as though you don't understand the '&&' operator - by using that, the OP has ensured that each file will only be removed if lame indicates (using its return code) that it completed successfully. Lame may lie, of course, but if you're concerned about that, then you won't want to automate this job at all. My experience indicates that it's extremely rare for a UNIX tool to lie in its return code value.

--

*BAM* Wish granted.

[devphil]

You are asking for programmable completion, which zsh and ksh have had for years, and bash just added a couple of point revisions ago. Look for the "bash completion" project at freshmeat to get a large library of hooks. Some distros already distribute the library, you just to turn it on (e.g., for Debian, uncomment some stuff in /etc/bash.something).

For ls, I type "ls --q<tab><tab>" and get a list of options beginning with q. For make, I type "make cl<tab>" and it completes the target name to "clean". And so forth.

I contributed one that does option completion for gcc, then somebody rewrote it. :-)

Re:The 'help' command

[zaphod110676]

I've never found info intuitive at all. The pinfo command however works great. It is a lynx style viewer for info pages. It required little work to figure out and is great when you hit those man pages that say:
"The full documentation for ls is maintained as a Texinfo manual."

Re:The 'help' command

[Nurseman]

"Can't be too hard for a bunch of geeks to sit down and work out a short list of 15-20 commands that you really *HAVE* to know for the CLI."

Do you mean like this ? Linux One Page Manual [powerup.com.au] Warning, it's a PDF, but it's pretty handy to me. Please dont kill his poor server.

Re:CLI vs GUI Ease of Use

[takev]

a CAD program has both.

It shows the drawing you can do most things with the mouse.

But on the bottom of the screen there is a command line interface where you can tell them where to draw the circle and be exact. It is very difficult to position objects on exact positions using the mouse. And filling in dialogue boxes is just slower then typing a command.