Forgot your password?
typodupeerror
Linux Software

The Command Line - Best Newbie Interface? 885

Posted by CmdrTaco
from the now-bloody-likely dept.
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."
This discussion has been archived. No new comments can be posted.

The Command Line - Best Newbie Interface?

Comments Filter:
  • The 'help' command (Score:5, Insightful)

    by nokilli (759129) on Tuesday March 09, 2004 @09:13AM (#8508731)
    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.
    • by pandrijeczko (588093) on Tuesday March 09, 2004 @09:16AM (#8508748)
      Just do an alias of "help" to "man -k".

      As long as "makewhatis" is setup first, that will do about the same thing.

      • by TehHustler (709893) on Tuesday March 09, 2004 @09:20AM (#8508789) Homepage
        And thats going to make sense to newbies how?
      • by PowerBert (265553) on Tuesday March 09, 2004 @09:27AM (#8508846) Homepage
        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'.
      • by Talez (468021) on Tuesday March 09, 2004 @09:36AM (#8508913)
        Nope. Sorry. man is crap for a newbie.

        What Linux needs is a MS-DOS 6 style help command. When you type help it pops up a nice ncurses screen of all the different commands available on linux systems, briefly what they do and a link that can take them to a simplified, easy to read page of advanced things to do with the command.
        • by mwing (664838) *
          I thought the apropos command was just for that purpose. Granted that newbies probably don't know to type that, but it is quite easy to have the console print a few helpful commands when the user logs in. Maybe the distro's should add a default motd to newbies?
        • by Skinny Rav (181822) on Tuesday March 09, 2004 @09:57AM (#8509085)
          What Linux needs is a MS-DOS 6 style help command. When you type help it pops up a nice ncurses screen of all the different commands available on linux systems, briefly what they do and a link that can take them to a simplified, easy to read page of advanced things to do with the command.


          How about info? man interface is crap, but info is pretty user friendly. OK, I admit, I mostly browse info in emacs where it is all flashy and colourful, but AFAIR it is quite easy to navigate also in console. Although a small bar with basic navigation keys on the bottom would help a lot. Of course still quite often if you type 'info foobar' all you get is a man page but that's a different story.

          Raf
        • by Angstroem (692547)

          What Linux needs is a MS-DOS 6 style help command. When you type help it pops up a nice ncurses screen of all the different commands available on linux systems, briefly what they do and a link that can take them to a simplified, easy to read page of advanced things to do with the command.

          Erm... So what exactly is a "command" by your definition? With DOS it was easy: everything which was embedded in command.com (thus the necessity to always carry an extra format.exe)

          On a Unix system, however, there's j

        • by fshalor (133678) <<fshalor> <at> <comcast.net>> on Tuesday March 09, 2004 @11:04AM (#8509743) Homepage Journal
          Sorry to dissagree.. Dos help was nice, but the dos TUI sucked for one reason: NO TAB COMPLETION! I am a Linux/Unix admin, and I can't function in environments without tab completetion without a fair amount of consternation, misstyped commands, web lookups and other crap.

          Every user I've ever seen strugging with tab decompletion shells almost instantly became functional when tab competion was introduced.

          Most people find that typing two letters and then tab can get them to anything they want to do faster than finding the mouse, finding the app, doubleclicking, etc.

          No, I will not make the mistake of stating "I love man".. But I can't work well without it most of the time.

          Maybe someone should write one for Linux, just for the heck of it. They can call it "woman". :) Then again, someone probably already has.
        • by mwood (25379) on Tuesday March 09, 2004 @01:00PM (#8510654)
          I will now reveal just how uncool I am by suggesting that you go take a look at the OpenVMS 'HELP' command. The wealth of information in a decent man page is like a revelation from heaven to one who has had to make sense of DOS HELP, but a single massive spew of everything known about some complex program is a little overwhelming even with an outstanding pager to help. VMS HELP documents are hierarchial and are usually chunked fairly nicely.

          Where VMS HELP falls down is in full-text searching, though that may have been improved since they took my VMS boxes away. It also needs a much better pager.

          'info' is pretty good, but there are a number of very poorly structured texinfo documents to deal with, the style suffers from doing double duty as the revisable form of a book, and somehow I've never reallly become comfortable with the keystroke assignments. OTOH texinfo's structural possibilities are a bit more flexible than the VMS Librarian's HELP mode, and a good document designer can do wondrous things with it -- the problem is the dearth of good document designers and a certain attitude in the community which says that documentation is for those who can't read source.
      • by selderrr (523988) on Tuesday March 09, 2004 @09:53AM (#8509034) Journal
        [ldab:~] selderrr% help alias
        help: Command not found.
        [ldab:~] selderrr% help help
        help: Command not found.
        [ldab:~] selderrr% help me
        help: Command not found.
        [ldab:~] selderrr% help me asshole !
        help: Command not found.
        [ldab:~] jeroen% can you help me ?
        can: No match.
        [ldab:~] jeroen% where can i get help ?
        [ldab:~] jeroen%
        [ldab:~] jeroen% find help
        help: help: No such file or directory
        [ldab:~] jeroen% locate help
        ... (machine goes off into dumping half my 150GB)
    • Doing the man command is probably too much for a true newbie. See 'man ls' or 'man nmap'.
      • Y'know what got me into the man command in a big way? Playing MUDs and learning to parse through steadily more complex help documentation as my character advanced and wanted to do more things. The docs in the MUDs I played were chatty, informative, helpful and most of all you could generally find out how to do what you wanted to do within the first page of help.

        I've been thinking for a while (after teaching students some HCI at least) about a game-driven OS UI. Takes me back to usability testing at $BigSo
    • by oingoboingo (179159) on Tuesday March 09, 2004 @09:30AM (#8508870)
      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.

      How about a little animated 'bash$' command prompt which jumps up when you hit F1, or which politely asks "It looks like you're composing a shell script. Would you like some help!" when you're in a bit of a pickle. You could type in a plain-English question about what you wanted to do, rather than having to remember the cryptic names of Unix commands. When you selected your specific query from a list of options that the animated character presented to you, it would then go on to show you exactly how to enter the command you were interested in. It would be great! You could even theme this 'assistant' according to your shell...it could appear as an animated 'ksh' or even just a '%' sign for those wanting to get on with the job.

      As for a name, what about 'Bob'?

    • by HidingMyName (669183) on Tuesday March 09, 2004 @09:35AM (#8508907)
      I suspect that new users find Unix/Linux challenging due to historical reasons. Two problems that stick out are command naming conventions and command output.

      It is an unfortunate artifact of Unix history that some of the commands are poorly named. The Help command did exist in Unix, but it was the help system for sccs (too bad there wasn't sccs --help or some such convention instead). There are a few other pet peeves of mine, grep might be better named search, etc.

      Command output is problematic since users often expect feedback. For example when we grep on a file and don't find the pattern, grep does not generate any output. From a programmer point of view that is definitely the right thing (especially since these commands are used as filters in a pipelined fashion), however, from a user centric point of view there may be an expectation of a report that the pattern was not found. I'm pretty used to the Unix/Linux way of doing things, but new users are not.

      • by gmack (197796) <.gmack. .at. .innerfire.net.> on Tuesday March 09, 2004 @09:52AM (#8509028) Homepage Journal
        When I was in highschool I switched my PC from windows 95 to Linux after my sister had damaged my windows install. After the initial horror at what I had done wore off, my younger brother and sister got used to the new system. Four months later I discovered they were both making extensive use of the command line. I hadn't tought them a thing so they learned on their own. By the time I moved out I had my mother using pine over ssh to read her email.

        Most of the trouble of Linux is the inertia related to not wanting to learn new things and not being technically difficult.
        • by A nonymous Coward (7548) * on Tuesday March 09, 2004 @10:44AM (#8509534)
          I loaded Linux on a Windows 3.1 machine for my kids to get mail (had a domain name) so they could all have their own mail accounts and login; didn't want the arguments from a 16 year old girl and 12 year old boy fighting over a common email account. The 16 year old liked Pine for email, she would rather exit X to read email under Pine, before she learned about xterm.
        • by JavaLord (680960) on Tuesday March 09, 2004 @01:43PM (#8511084) Journal
          By the time I moved out I had my mother using pine over ssh to read her email.

          Most of the trouble of Linux is the inertia related to not wanting to learn new things and not being technically difficult.


          Yeah I know what you mean. When I was in high school I used to visit my grandmother in a nursing home all the time. She didn't know how to use Windows or E-Mail so I just gave her an old linux box. Like 2 months later she had root at NASA.
      • by Anonymous Coward on Tuesday March 09, 2004 @10:11AM (#8509203)
        > Command output is problematic since users often expect feedback. For
        > example when we grep on a file and don't find the pattern, grep does not
        > generate any output.

        Try this:

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

        This puts a little :) on the prompt if the previous command succeeded,
        and a :( if it failed.

        It doesn't help if the command was part of a pipeline or some such,
        but it's debatable what sort of feedback you want if something
        in the middle of one of them is unhappy.
      • by Anonymous Coward on Tuesday March 09, 2004 @10:25AM (#8509319)
        Yeah, there needs to be another default output stream. stdin, stderr, stdout and stdidiot. Stdidiot is where you tell the user verbose output of what you are doing including positive affirmation! Jack Handy beware. Of course one should be able to setenv STDIDIOT=/dev/null to turn that off. Moreover, maybe you re-direct it into a pipe that a consolish app could tail? Then a little ticker window on the desktop closes the loop for those needing positive responses?

        Ok the name was tongue-in-cheek. But maybe there is something the idea. I've been living in Unix for more than a dozen years and most of the time I like the "tell me about it iff there are problems" philosophy, but a centralized ticker might occasionally be handy. As a first cut one could basically write a layer that takes the stuff spewed forth by most utilities when -verbose is kicked in and peel it out to stdidiot. If -verbose is thrown on the cmd line, then stdidiot is echoed to stdout too.
    • by zymurgy_cat (627260) on Tuesday March 09, 2004 @09:38AM (#8508933) Homepage
      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.

      What I'd really like to see is a more helpful man page with examples. It's frustrating when using a new command to read "usage: foobar [VNFHDMudndghfud8734yfhfnbgdh] filename | device | dir | options filename[]" and then read through 5 pages of options and switches I'll never use. If every man page had at least a few examples of how to do stuff most people want to do, it'd be easier to both do those things and learn the more complex commands.

      Another nice thing would be a howdoi command which allows the input of natural language and spits out a small man page (with examples!) or help file, ie, "$>howdoi see how much hard drive space i have" spits out how to use df.
      • Try 'man rpm' (Score:5, Insightful)

        by Black Perl (12686) on Tuesday March 09, 2004 @11:42AM (#8510042)
        RPM is supposed to be easy to use... but the dang man page is so long... Here's just the SYNOPSIS section at the beginning:

        NAME
        rpm - RPM Package Manager

        SYNOPSIS
        QUERYING AND VERIFYING PACKAGES:
        rpm {-q|--query} [select-options] [query-options]

        rpm {-V|--verify} [select-options] [verify-options]

        rpm --import PUBKEY ...

        rpm {-K|--checksig} [--nosignature] [--nodigest]
        PACKAGE_FILE ...

        INSTALLING, UPGRADING, AND REMOVING PACKAGES:
        rpm {-i|--install} [install-options] PACKAGE_FILE ...

        rpm {-U|--upgrade} [install-options] PACKAGE_FILE ...

        rpm {-F|--freshen} [install-options] PACKAGE_FILE ...

        rpm {-e|--erase} [--allmatches] [--nodeps] [--noscripts]
        [--notriggers] [--repackage] [--test] PACKAGE_NAME ...

        MISCELLANEOUS:
        rpm {--initdb|--rebuilddb}

        rpm {--addsign|--resign} PACKAGE_FILE ...

        rpm {--querytags|--showrc}

        rpm {--setperms|--setugids} PACKAGE_NAME ...

        select-options
        [PACKAGE_NAME] [-a,--all] [-f,--file FILE]
        [-g,--group GROUP] {-p,--package PACKAGE_FILE]
        [--fileid MD5] [--hdrid SHA1] [--pkgid MD5] [--tid TID]
        [--querybynumber HDRNUM] [--triggeredby PACKAGE_NAME]
        [--whatprovides CAPABILITY] [--whatrequires CAPABILITY]

        query-options
        [--changelog] [-c,--configfiles] [-d,--docfiles] [--dump]
        [--filesbypkg] [-i,--info] [--last] [-l,--list]
        [--provides] [--qf,--queryformat QUERYFMT]
        [-R,--requires] [--scripts] [-s,--state]
        [--triggers,--triggerscripts]

        verify-options
        [--nodeps] [--nofiles] [--noscripts]
        [--nodigest] [--nosignature]
        [--nolinkto] [--nomd5] [--nosize] [--nouser]
        [--nogroup] [--nomtime] [--nomode] [--nordev]

        install-options
        [--aid] [--allfiles] [--badreloc] [--excludepath OLDPATH]
        [--excludedocs] [--force] [-h,--hash]
        [--ignoresize] [--ignorearch] [--ignoreos]
        [--includedocs] [--justdb] [--nodeps]
        [--nodigest] [--nosignature] [--nosuggest]
        [--noorder] [--noscripts] [--notriggers]
        [--oldpackage] [--percent] [--prefix NEWPATH]
        [--relocate OLDPATH=NEWPATH]
        [--repackage] [--replacefiles] [--replacepkgs]
        [--test]



        Each of the above options is explained in detail, but there are no FAQ-style examples. It's no wonder the distributions are putting layers on top of rpm (urpmi, yum, etc). I like yum, and largely because the man page is short and to the point! It only takes a few seconds to figure out what I need to do.
      • by NMerriam (15122) <NMerriam@artboy.org> on Tuesday March 09, 2004 @11:46AM (#8510085) Homepage
        I will agree with this wholeheartedly. This is a place where DOS did it right and no linux distro yet has matched.

        If you type foo /? in DOS, you'd get a one or two page SUMMARY of how to use the command, half of which was EXAMPLES of how to format command lines for different tasks. 95% of the time this was all that was needed -- for more details, you'd get a book.

        Most Linux man pages are the exact opposite -- they tell you how to do everything under the sun over 20 pages of text, but never show how those options actually fit together on a command line. That is useful information, but it takes for granted that there are NO ambiguities whatsoever, which is very, very rare.

        Show 5 or 6 examples and the "unwritten" rules of how to format the command can be quickly grasped in a way that 200 pages of specs could never make clear.
    • by G4from128k (686170) on Tuesday March 09, 2004 @09:59AM (#8509097)
      Having done everything from assembly language programing for embedded systems to UNIX CLI (Command Line Interface) to Macintosh, I find that CLI is distinctly inferior to GUI (Graphical User Interface) for all but a few tasks. I challenge CLI users to do any form of word processing from a shell prompt. Even the most hard-core of them will resort to vi or emacs which use a primitive pseudo-GUI (and yes you can create and I have used a pure CLI text editor, but it is extremely painful). I don't want to even think about trying to replicate Photoshop with a CLI.

      CLI = Dialog? The article mentions the notion of CLI as a dialog. But this is a misleading metaphor because so many CLI commands create invisible effects. You tell the computer to do something and all that returns (in most cases) is a command prompt. At best its like teaching someone to to do a job while speaking through a door. You give a command to do something (e.g., move a file from directory to another) and then you have to give a command to see the results (ls).

      Discoverability: GUIs also provides visibility on to the set of available commands and functions. By browsing through the menus (which are usually nicely organized), you can learn the functions of an application. In contrast, a CLI-only machines provides no obvious way to learn about commands that you did not know existed -- at best you can access an alphabet soup of cryptic vowelless cmmnd names and then access the man page on each command. Therefore, GUI applications tend to be self-documenting, CLI commands require that you first know of the existence of the command and then you must read the man pages (grepping the man pages sometimes works if you know the jargon for what you are looking for).

      Undo command: Most well-behaved GUI applications further support user learning via experimentation by having an undo command (and a revert command). CLIs tend to be irrevocable with no possibility for undoing inadvertent damage by a novice user (short of reloading the entire machine from a backup). Its no wonder *nix people get upset at the thought of novices on computers. But this lack of an "undo" is the fault of *nix CLI (it could easily be remedied with automatic file version tracking and journalling).

      GUI is the superset of a CLI: Some people complain that GUIs take too long and I agree with them. CLI does offer a faster interface for experienced users. Yet a good GUI offers keyboard shortcuts that let experienced users invoke commands from the keyboard. While it is easy to have a keyboard shortcut available and shown in a mouse-oriented graphical GUI menu, it is hard to have a graphical menu shortcut in a keyboard-oriented CLI. With a GUI that shows the shortcuts in the menus, the user can learn shortcuts as they use the machine. Thus, I would argue, a GUI is the superset of a CLI.

      Direct Manipulation: And CLI's inferiority is not just a matter of the learning curve (although that is a big disadvantage of CLI). For some tasks, a direct-manipulation WYSIWYG GUI is vastly superior. I challenge *nix people to build a CLI-only version of Photoshop. This is more that a matter of ease-of-use it is a matter of creating a coordinated interface between a person and a machine. While CLI forces the user to preform a completely defined action (e.g., type in a command that turns pixel 100,103 in file x to RGB value 128,128,200), a GUI lets the user try something (select a paint brush tool from the toolbox, test it somewhere, undo, use the tool somewhere else, etc.)

      Control Panels vs. Config Files: The article claims that modern GUI-driven OS have too many control panels ("To master modern GUIs, one must recall the operation, layout and relation to each other of hundreds, if not thousands, of such panels." Yet how is this same functionality attained in a CLI machine? Config files are the absolute worst because they offer no form of input checking or potential for embedded help. Most config f
      • by Lussarn (105276) on Tuesday March 09, 2004 @10:26AM (#8509323)
        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.
      • by Jorrit (19549)
        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.

        Greeti
      • by thelexx (237096) on Tuesday March 09, 2004 @10:56AM (#8509644)
        You're harping on a 'CLI Photoshop' is pretty retarded. Even before OS based GUI's were common, there were these things called 'drawing programs' that provided their own. Nobody I know of has EVER claimed a program like that, meaning one that explicitly deals with friggin graphics, would be better off as a command-line app.

        Also, as far as config files go, ninety-five percent of the time there's no or little help available in settings dialogs. Not to mention multiple tabs, trees, checkboxes that can be overlooked, etc. With a config file you generally have one big list of settings that you can SEARCH, instead of clicking on shit for five minutes wondering where the hell that setting was.

        File navigation is hit and miss on both sides of the argument IMO. I tend to work with the same paths enough to remember them, and I can guarantee I'm faster using the command line when I'm dealing with known paths. OTOH, when I'm not sure where something is or am kind of browsing, a GUI is better. Or 'pseudo-gui' as I think you called it - Midnight Commander. It utterly annihilates any and every gui file manager I've ever used. It has the best of both worlds, an extremely effective 'pseudo-gui' and a command line.

        Finally, GUI as a _superset_ of the command line? Now I know you're high. Maybe on Windows. Under Linux it's a distant and pale subset. End of story.

        Overall, it really just sounds like you have an axe to grind.

        "The bottom line is I want to "use" my computer, not "learn" my computer."

        And there it is.
      • by frog51 (51816) on Tuesday March 09, 2004 @11:13AM (#8509853) Homepage Journal
        At risk of just sounding argumentative, I actually disagree on almost every point you have just made. My background has led me through assembly and machine code in the days of 6809, 68000, Z80 and 6502, through Pascal, Forth, VB, C++ etc etc so I have had a fair amount of experience of various platforms, and the one thing I have learned above all others is how inferior a GUI usually is.

        I agree that word processing is generally easier with a WYSIWYG word processor, but there are damn few of them. If it comes down to needing a specific layout, I know LaTex will work where MS Office often fails. And any graphical manipulation should be easier using graphical tools.

        But your other points:
        CLI = Dialog? The article mentions the notion of CLI as a dialog. But this is a misleading metaphor because so many CLI commands create invisible effects. A GUI has far more invisible effects, as you can't even tell what commands it runsYou tell the computer to do something and all that returns (in most cases) is a command prompt. A Unix command which returns a prompt implies it completed. Error codes are output from almost everything, and if you want to see them you can.At best its like teaching someone to to do a job while speaking through a door. You give a command to do something (e.g., move a file from directory to another) and then you have to give a command to see the results (ls).Or alternatively, you give the command and trust the agent to perform its duties and only return an issue when there is a problem

        Discoverability: GUIs also provides visibility on to the set of available commands and functions. By browsing through the menus (which are usually nicely organized)Some are nicely organised, and to be fair, this is an area where there is great improvement, but in general I find it a nightmare to have to drop down through menu after submenu, sometimes in unintuitive places, to carry out a simple command., you can learn the functions of an application. In contrast, a CLI-only machines provides no obvious way to learn about commands that you did not know existed -- at best you can access an alphabet soup of cryptic vowelless cmmnd names and then access the man page on each command. Therefore, GUI applications tend to be self-documenting, CLI commands require that you first know of the existence of the command and then you must read the man pages (grepping the man pages sometimes works if you know the jargon for what you are looking for).There is an argument for simpler documentation than 'man' pages, but in reality, all that I think would be required is some indexing system.

        Undo command: Most well-behaved GUI applications further support user learning via experimentation by having an undo command (and a revert command). CLIs tend to be irrevocable with no possibility for undoing inadvertent damage by a novice user (short of reloading the entire machine from a backup). Erm...novice user...should not have access to anything other than their own files, so should not cause irreversible damage. If they do have root, well, that's kind of the same as letting newbies have administrator access on Windows machines...a very bad idea. There should be no need. Its no wonder *nix people get upset at the thought of novices on computers. But this lack of an "undo" is the fault of *nix CLI (it could easily be remedied with automatic file version tracking and journalling). What do you mean by undo anyway? An undelete? Easy. A 'revert back to before I overwrote that file with this one' option? Does your GUI give you that?

        GUI is the superset of a CLI: Some people complain that GUIs take too long and I agree with them. CLI does offer a faster interface for experienced users. Yet a good GUI offers keyboard shortcuts that let experienced users invoke commands from the keyboard. While it is easy to have a keyboard shortcut available and shown in a mouse-oriented graphical GUI menu, it is hard to have a graphical menu shortcut in a keyboard-or
      • by Christianfreak (100697) on Tuesday March 09, 2004 @11:17AM (#8509898) Homepage Journal
        Nice troll. Looks like the mods went for it too.

        All systems have a learning curve, if they didn't I wouldn't have the same Windows user calling me everyday because she forgot how to get her email.

        CLI = Dialog? it depends on the command, and no one said some commands couldn't be rewritten to be more userfriendly. Besides it wouldn't take long for people to know which commands aren't going to return anything if they fail and come to expect that. In fact some of us with a bit more experience like these commands as they can be chained together to do even more useful and exciting things.

        Undo command: Actual commands to the OS can't be undone in any environment. Once you click 'OK' in some dialog (commanding the OS to do something) That's it, there is no resetting from that point. The CLI is closer to the OS in most cases. So the fact that it has no undo isn't really all that surprising. Many (usable) command interfaces have a command history however so undoing something usually isn't all that hard. Many commands such as cp and rm have confirmation dialogs turned on by default so you are less likely to make a mistake in the first place.

        GUI is the superset of a CLI: Can you operate the machine using Ctrl+This and Ctrl+That without the GUI?

        Direct Manipulation: What a pointless argument. The CLI has nothing to do with the applications you are using. I think most people talk about using a CLI to get around their systems. No one is advocating making graphical image applications, web browsers or games go away! As for your challenge such a thing does exist, its called ImageMagick (the convert command) you can manipulate pictures from the CLI and you can do a lot with it. Of course its a command designed to filter things and program with (ImageMagick itself is an API) just like lots of other commands on the system.

        Control Panels vs. Config Files: I'll keep my config files thanks. Very few widely used config files aren't littered with all kinds of comments telling you exactly what to enter. And of course there is input validation. Many programs have a 'check the config file mode', and even if they don't its probably not going to run with an invalid config file. Editors such as VIM help here too. When the syntax is supposed to be highlighted a certain way and suddenly its not, there's probably a problem.

        Pathnames: Tab-completion?

        Your argument about single files goes away with tab-completion too. Really I wish there were better ways to select groups of files (by type maybe) in a CLI for batch transfers.

        Personally I want to "use" my computer without pretty pictures getting in the way. Bill Joy probably made those statements because he isn't familiar with Linux. I've set down in front of Mac OSX and whenever I have I end up looking for the Terminal.app so I can use the comptuer.

    • by DrXym (126579)
      Another neat feature would be inline expansion of arguments.

      At the moment if you hit TAB on the command line it will autocomplete a file name. For example if I type "more /etc/pr" and hit TAB it expands out to "more /etc/profile". But TAB doesn't help if I'm typing in other arguments.

      Now imagine the TAB behaviour was smart and used the command context to that. For example, it might know that if I type "ls -" and hit TAB, that it should list the most common flags with a brief description for each. If I t

      • by Skweetis (46377) on Tuesday March 09, 2004 @11:55AM (#8510179) Homepage
        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.
  • Mac OS X (Score:4, Insightful)

    by jammer 4 (34274) on Tuesday March 09, 2004 @09:15AM (#8508741) Homepage
    And isn't it nice that Mac OS X now gives you the best of both worlds :)
    • Re:Mac OS X (Score:4, Insightful)

      by baryon351 (626717) on Tuesday March 09, 2004 @09:24AM (#8508829)
      I think so

      I don't believe the importance of a really refined gui is as high as it used to be. Back when the original mac was introduced, along with other later GUI based systems such as the Amiga, it was brand new. Newbies back then were far newbier, and it wouldn't be unusual to find 98% of the population who had never used a computer, EVER.

      Now in the same society you'd be hard pressed to find a third grader who hasn't used a computer for nearly a year. The skills are being embedded at a younger and younger age. The big difference between a machine thats intuitive now, and one thats not, is the one that doesn't crash is more usable. Not much more than that
    • Re:Mac OS X (Score:3, Insightful)

      by Zone-MR (631588)
      And isn't it nice that Mac OS X now gives you the best of both worlds :)

      Linux has done the same ever since X came into existance.

      Windows has always supported a command prompt too, just the majority of users don't have a clue on what it is, or how to use it.

      IMHO only a subset of the intrinsic OS utillities can be properly used via the GUI. As an example I often want to transfer files from my digitial camera. The camera saves the files as "DSCF0001, DSCF0002, ...". Sometimes I want to move the contents o
  • 4Dos (Score:4, Interesting)

    by swordboy (472941) on Tuesday March 09, 2004 @09:16AM (#8508742) Journal
    Does anyone remember 4Dos [jpsoft.com]? Between that and Qmodem, I learned a whole lot about computers.
    • Re:4Dos (Score:5, Informative)

      by muffen (321442) on Tuesday March 09, 2004 @09:24AM (#8508826)
      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...
  • by scsirob (246572) on Tuesday March 09, 2004 @09:16AM (#8508746)
    I find it amazing how many computer "experts" are dead in the water when the mouse doesn't work or the GUI doesn't come up as expected.

    Too bad only the "old-timers" seem to appreciate the power of the keyboard.
    • by chunkwhite86 (593696) on Tuesday March 09, 2004 @09:21AM (#8508793)
      I find it amazing how many computer "experts" are dead in the water when the mouse doesn't work or the GUI doesn't come up as expected.

      These same so-called "experts" tend to have MCSE certificates proudly displayed on their cubical wall.
    • by w1r3sp33d (593084) on Tuesday March 09, 2004 @09:36AM (#8508922)
      And many of us still use the most powerful keyboard ever created, the IBM (super-clicky) Model M. The sound of these keys has been known to kill users at twenty feet and drive MCSE's mad.
    • by adept256 (732470) on Tuesday March 09, 2004 @10:09AM (#8509188)
      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.

    • by Moraelin (679338) on Tuesday March 09, 2004 @10:49AM (#8509567) Journal
      Well, I'm an "old timer" who does _not_ appreciate the command line.

      By "old timer" meaning, admittedly, not 60 years old and having started on punched cards and electronic tubes.

      I did, however, learn programming in hex, not even assembly, on a ZX-80 with 1K RAM. In 1K you didn't even have space to run an assembler. I had a big old paper notebook with 1 page per command and a matrix of the registers involved. E.g., this is the page for "ADD", take the column for "A" and the row for "B", and there you have the hex code for "ADD A, B".

      I continued through such mis-haps as editing source files on a CP/M machine with a hex-based disk editor, because the PHB forgot to also give us a text editor. Sad, but true.

      You know what? I _don't_ miss those days.

      The command line is powerful and all, as long as you already know _exactly_ what you're doing. It is a pain in the donkey when you don't.

      The time and effort to get past that learning curve is not fun, and not what Joe Average wants. Heck, it's not what _I_ want.

      I do _not_ find it fun to spend hours digging through obsolete, incomplete man pages just to find out that I need to type some obscure command like "obscureProgram.sh -XFGXRmnq -i filename1 -o filename2 -c OBSCURE_COMMAND_CODE -p some_obscure_regexp -f unix-style-font-name" just to get something done. Bonus points if it expects me to already be in some directory, and some obscure configs to already be set right. More bonus points if it doesn't even do the whole job, but expects me to pipe it through other obscure programs. Double bonus if it outputs some cryptic error messages like "1962 Short School Bus", that don't even tell me what the **** went wrong there.

      Gimme a break. My time is too valuable to spend it on that kind of crap.

      Give me a GUI which has input fields for the stuff I need to enter. If it's a file name, give me a good file selector dialog, don't expect me to manually list directores 20 times to find it. If I'm supposed to enter options, give me checkboxes, radio buttons, or drop down combos. And, ffs, give me an up to date help for it. And clear, humanly understandable error codes.

      And you know what? I'm surprised how much energy goes into defending the sacred right to produce crap code and piss-poor interfaces.

      Here's an idea: if half the time that went into whining about how the 60's command line interfaces are better for the user, went instead into throwing together a simple user-friendly TK or ncurses or whatever GUI, we'd all be far better off than we are today.

      And let me get back to the part where I've said "The command line is powerful and all, as long as you already know _exactly_ what you're doing. It is a pain in the donkey when you don't."

      The problem there is that to get to know exactly what options to type there, you have to invest ludicrious ammounts of time into that. Which for most people isn't justified. If you'll configure printing on your home network maybe 4 times in your whole life, consider the following two situations:

      1. spending 4 hours to learn how to do that with CUPS and only with command line tools. But then you can do that in 30 seconds flat each time.

      2. spending 5 minutes each time doing the same in Windows, through the GUI

      Believe it or not, solution 1 is _not_ an improvement. On the whole, the l33t Unix command line way took 4 hours from your life, while the point-and-drool Windows way took a total of 20 minutes. The winner is... the GUI.

      Yearly millions of hours go into just learning to use some crap software. It isn't learning some l33t skillz, it isn't "getting a clue", it's just _wasted_. It's time when you're _not_ doing what you needed to do in the first place. Time where, like in the example above, instead of already having your file printed on that networked printer, you're still searching through obsolete man pages and trying stuff that fails for no obvious reason.
      • by Dun Malg (230075) on Tuesday March 09, 2004 @11:18AM (#8509913) Homepage
        Double bonus if it outputs some cryptic error messages like "1962 Short School Bus"

        That's a great error message. I think I'll create a whole class of "short bus errors" on the app I'm developing for work.

      • by toiletmonster (722398) on Tuesday March 09, 2004 @05:50PM (#8514128) Homepage
        I do _not_ find it fun to spend hours clicking through obsolete, incomplete help dialogue boxes just to find out that I need to click a checkbox in some obscure dialogue box and have to guess if its the customize menu option or the options option and then click through all 15 tabs searching for the checkbox. Bonus points if the option is disabled or expects some obscure registry key to set. More bonus points if clippy or some other annoying dialogue box pops up asking if i'm really sure i want to do that. Double bonus if my program crashes and without an error message, or i get a bsod which outputs some cryptic error messages like "1962 Short School Bus", that don't even tell me what the **** went wrong there. Not to mention customizing a shell script is a lot easier than customizing a gui. Not to mention you can't script guis.

        Gimme a break. My time is too valuable to spend it on that kind of crap.

        Give me a CLI which has prompts me for the stuff I need to enter. If it's a file name, don't give me a file selector dialog where i have to manually click through 20 directores to find it. If I'm supposed to enter options, don't give me checkboxes, radio buttons, or drop down combos. And, ffs, give me an up to date help for it. And clear, humanly understandable error codes.

        And you know what? I'm surprised how much energy goes into defending the sacred right to produce crap code and piss-poor interfaces.

        Here's an idea: if half the time that went into whining about how the 80's graphical user interfaces are better for the user, went instead into throwing together a simple user-friendly shell script or learning how to use existing cli interface we'd all be far better off than we are today.

        Yearly millions of hours go into just learning to use some crap software. It isn't learning some l33t skillz, it isn't "getting a clue", it's just _wasted_. It's time when you're _not_ doing what you needed to do in the first place. Time where, like in the example above, instead of already having your file printed on that networked printer, you're still searching through obsolete help dialogues and trying stuff that fails for no obvious reason.

        look. point taken that for some people in some situations, point and drool might be better. i'm a cli advocate, but not for every situation. but a lot of the things you mention are just poor program design. i like having man pages and open source because if something doesn't work i've got real in depth documentation and if i have to, i can figure out what the heck is wrong. with a gui in a closed source world, you are just sol. even with a gui in an open source world, the code is more complex and less accessible. granted this is not for newbs, but it does help non newbs. and it gives newbs an option to become non newbs -- they can learn if they want. if they don't want, then hey nothing lost.
  • purely anecdotally (Score:5, Insightful)

    by Transient0 (175617) on Tuesday March 09, 2004 @09:16AM (#8508747) Homepage
    It seems to me that if you start someone on a command line versus starting them on a GUI they learn a little slower but acquire a deeper understanding of the computer.

    point-and-click and drag-and-drop don't encourage any actual understanding of ways in which a computer interprets commands.
    • by Ubi_NL (313657) <joris@ideeelHORSE.nl minus herbivore> on Tuesday March 09, 2004 @09:23AM (#8508816) Journal
      Don't you nerds get it??

      I don't WANT to understand how my computer operates internally, just as much as I don't give a toss for how my car or my phone works.

      I just want to type a friggin letter.

      (This is not a troll, but to show that slashdotters are not really a typical representation of the worlds population)
      • by Anonymous Coward on Tuesday March 09, 2004 @09:40AM (#8508952)
        The issue here is that while you have no desire to find out how your computer works, YOU STILL NEED TO. The common analogy is that people rarely would think it makes sense for someone to buy a car with no clue how it works, even if you only understand fail conditions.
        Before you say you have no idea, if you live in the US, you did have to a test before you were allowed on the road, if you recall, and in that bank of questions there are fail conditions, such as driving on ice, perhaps even dealing with bug related Emergencies ( The long test to pass driver's ed around here included some very amusing questions about what to do when you discover a bee in your car )
        However, people rely heavily on their computers and never try to learn basic fail conditions, like file location, full disk problems, uninstalling undesired programs, checking for updates. I'm not saying everyone needs to have a nitty gritty look at their kernel source, but you should know the difference between an ISP and AOL. You PAY for this stuff, you should have a vague idea of how it works and first steps on how to fix it when it breaks.
        If you happen to be a supreme fool that knows so little about your car that you can't tell how fast it's goings, whether the engine is running hot, how to tell if your brakes need servicing ( waiting for the grind counts ), or the meaning of any of those "little flashy lights" on your "long window thing the steering wheel is hooked under", I pity you and your genetic tree.
        • by HeghmoH (13204)
          Bingo!

          People who don't understand how their car works beyond turning the ignition and pushing the gas are the type of people who drive their car for ten thousand miles without an oil change, and then scratch their heads when their car just up and dies. You must have at least a basic understanding of what's going on inside your car in order to be able to use it effectively. Yet many people are completely unwilling to invest an equivalent amount of time to gain an equivalent amount of understanding of their
        • by alexhmit01 (104757) on Tuesday March 09, 2004 @10:58AM (#8509655)
          Look, if the car starts bouncing, I know I have a flat tire. If the engine is having problems, a red light on my dashboard tells me to take the car in. When the car struggled to shift gears, I knew it was a transmission problem. The CAR informs me of what is needed and I take it to the specialist. The basic maintenance schedule is given to you when you buy your car, there are no surprises.

          Regarding a license... you need a license because with an automobile because the misuse of an automobile can endanger others.

          Look, I'm a computer engineer by training, know my way around Unix, know my way around NT (MCSE, CCA from old career), and know my way around a CLI. Guess what, when I want to put together a business model, I want a graphical spreadsheet that is out of my way. Do I know ALL the Excel functions? No, but I know the ones I use regularly, and the help system gets me through the rest.

          I have no desire to memorize arcane commands, I want to build the business model. Will I learn arcane commands to speed things up? Sure, but on MY schedule, NOT yours. I buy the machine to let me get my work done, and I pay the premium for a laptop to do so on the road, and I pay the (admitted small these days) Apple premium to have wireless support that is amazing and to be able to have my Unix applications on the road. These are all my choices.

          Guess what, I don't pay Open Source programmers, so they don't have to listen to me. However, don't complain that I don't have an open source desktop when you put out bizarre GUIs that interfere with my workflow.

          My Mac stays out of my way and lets me do work, MUCH faster than Windows or Linux would let me. In the end, that keeps Linux a step away from "global domination" or whatever the goal of the week is.

          My computer should work for me, not the other way around. Sure, I had to demonstrate an understanding of traffic laws to get on the road. But guess what, EVERY car I drive is nearly identical, and the controls don't change. That consistent UI makes cars a success.

          Windows has problems, no question. But it is "good enough" for most, and it is pretty cheap.

          For a single-purpose machine, Linux is fine, I can train my people on 1-2 applications... If GNUStep was further along, or Qt didn't blow as a RAD tool, then our dedicated personnel would be on Linux machines and not eMacs. However, if you think that Linux is good enough for a business power user, you're sadly mistaken.

          The integration of the Office Suite has been AMAZING for a few years, and the combination of Word, Excel, and Powerpoint is TERRIFIC for business users. Until GNU can mimick that power (NOT mimick the widgets, but the power and integration) then it is NOT a viable desktop system for the modern business power user.
        • by dasmegabyte (267018) <das@OHNOWHATSTHISdasmegabyte.org> on Tuesday March 09, 2004 @11:45AM (#8510082) Homepage Journal
          Whoa. The guy said he doesn't want to know how his computer works. He didn't say he didn't want to know how to prevent it from breaking. These are two completely separate things. Ignorance of the mechanical engineering of combustion engines does not preclude following a maintenance schedule, in fact my wife (who knows NOTHING about cars) is far better at maintaining her car than I am at mine, because she knows when to defer to authority.

          You see, this is the problem most everyday people have. They want to run a computer, perform tasks, and prevent themselves from running into problems. And when they ask how, the average "computer guy" starts running down lists of commands and protocols and the history of DOS. These things are excellent trivia, but they're not analogous to what you're saying here. The end result is this: the computer looks more complex than it is. And complex things are hard to use, right? So why bother?

          You can show somebody how to use Uninstaller and Windows Update without showing them the command line, and in far less time. In fact, I can't imagine where either of these functions, essential to the use of a GUI based machine, has any real bearing in the command line. Certainly I've never Run->CMD to get rid of that stuff...

          Using the command line doesn't make you any more knowledgable about how to secure a computer or choose an internet provider than knowing how a carburetor works tells you how many miles you can drive on that loose bearing before it seizes. People who know their shit about cars still have engine problems and get into accidents. They still pay the same blue book value to get the car fixed. They're just better at explaining the problem.

      • by Zardoz44 (687730)
        I wholeheartedly agree. Despite being a male, I think this car is the way to go:

        Designed for Women [bbc.co.uk].

        I don't need to assert my masculinity with a fast&furious Dodge Neon. I want a car that I can get in and drive. Does it need gas? Fine. Does it need washer fluid? Fine. Oil change? Give me an easy-to-access location for removing the old and adding the new. Point being, I just want it to work.

        This is the same with computers. I program them for a living, but when I want to use one, I just want to use i

      • by martin-boundary (547041) on Tuesday March 09, 2004 @09:56AM (#8509075)
        Don't you lusers get it?

        We don't care that you don't want to know how your computer works. We like discussing interfaces and tech lawsuits. That's what we want to do, not type friggin letters or pay the bills over the internet. Different websites for different people. This is slashdot.

      • by rbolkey (74093) on Tuesday March 09, 2004 @10:14AM (#8509223)
        just as much as I don't give a toss for how my car or my phone works.

        Please change the oil in your car. And that rattling sound is your catalytic converter. The squeeking sound is your brakes. Just a heads up.
      • by ControlFreal (661231) * <niek@bTOKYOergboer.net minus city> on Tuesday March 09, 2004 @10:29AM (#8509361) Journal

        I understand your frustration, but also disagree with it. Allow me to explain.

        The concept you're bringing up is black boxing [wikipedia.org]: a simple (or standardized) user-interface that hides a complex system.

        The pros of black-boxing are obvious: black boxing makes it possible for many people to operate complex equipment (think cars, phones, computers). There is also a psychological factor at play here: as many people seem to suffer from self-learned helplessness when dealing with technology, black-boxing (e.g. think nice-and shiny i-POD, or automatic-transmission lady-car) helps them to overcome their physological aversion and acutally use the device.

        Now, as already stated by another user, the main con of black-boxing is what happens when something goes wrong: black-boxing provides a very poor way of dealing with failure-conditions!. There is also another con, which is public perception: black-boxing makes people believe that the equipment they are operating is simple, while in reality it's very complex. But because they reason from their internal "simple make-believe model', they can make mistakes that they wouldn't have made, had they known a bit more about the equipment.

        To provide an example: Here in Europe, most cars are manual transmission (typically 5 forward and 1 reverse). When driving 80 kph in a flat country like holland, it really doesn't matter that much whether you drive in 3rd gear of 5th gear. However, when some Dutch people drive through Switzerland during the summer holidays (with a big trailer behind the car), they persist in driving in 5th gear up-hill, their argument being: "Hey, don't worry man, the car maintains speed uphill, so what's the problem". Of course, had they known a bit more about how an engine works, they would have switched back to 4th (or even 3rd) gears, to allow the engine to run at a higher specific torque, and to allow the cooling fluids to be pumped around more quickly to cool the engine better. Our black-boxing people usually end up overheating their engine (and blocking traffic and creating big jams in the Alps, grumble! ;) You see: it pays to know at least a bit about what's under the black cover of your black box!

        In the same way, your shiny XP thingy makes your computer seem a simple device. But of course, it is still a really complex device. We've all seen people do stupid things because they persisted in acting according to how they believed the computer works (their simple model), rather than basing their actions on how the computer actually works. Knowing a bit about the latter, however small, enables you to do better in times of failure, but also in general.

        On a personal account: I learned C after I learning assembly. I experienced this as a big bonus, because after using asm, you know what pointers actually are and how they work. I've seen people program Java and doing stupid memory allocation things, because they had no clue about what happens when you do "new bla" or "delete bla".

        To conclude: black boxing is ok, but you need to keep in mind that you are still operating a complex device!

    • by nickos (91443) on Tuesday March 09, 2004 @09:27AM (#8508849)
      "point-and-click and drag-and-drop don't encourage any actual understanding of ways in which a computer interprets commands."

      How does moving a file using the command line rather then dragging and dropping it in a GUI encourage "understanding of ways in which a computer interprets commands"? They're just different interfaces.

      If I install some speech recognition software on my Mums Windows box, will the new command based interface encourage "understanding of ways in which a computer interprets commands"?

      While most users who know how to use the command line also have a good understanding of how computers work, this knowledge is not the result of them having to use the command line.
      • by muckdog (607284)
        How does moving a file using the command line rather then dragging and dropping it in a GUI encourage "understanding of ways in which a computer interprets commands"?

        Feedback and the ambigousness of GUIs. "Did the drag and drop copy the file or move the file?" It depends. "Did it move my program or create a fucking shortcut for it in the new folder?" Not sure where you holding the shift key. The slowness of GUI also contributes to it too. How many time have you clicked on the X to close a windows when i
  • by Xpilot (117961) on Tuesday March 09, 2004 @09:17AM (#8508757) Homepage
    Apprentice: "What is that, Master?"

    Master: "It's a command line. The instrument of a Unix Programmer. Not as random or clumsy as a GUI. An elegant interface for a more civilized age. Before the dark times. Before...Microsoft!"

  • Well (Score:5, Insightful)

    by odano (735445) on Tuesday March 09, 2004 @09:18AM (#8508769)
    I believe it is because the command line is very simple and compact, single-threaded and simple to understand.

    Modern GUIs have many things going on at once, which can confuse people who have no idea what is going on. Windows pop up, there are icons to deal with, they have to search through endless menus to find what they want.

    The command line however has simple command to remember instead of complicated graphical procedures, and the status of the command line really never changes. If you mess something up, you are still back where you started, but in the GUI, a user could close a window to open another one which obviously confused people who don't understand what they mean.
    • Re:Well (Score:5, Interesting)

      by SvendTofte (686053) on Tuesday March 09, 2004 @09:36AM (#8508917)
      Sounds like the people here have no idea what makes GUI's so powerfull.

      1. State. You can (should) always at a glance be able to see what state the system has. With a CLI interface, there's simply no state. It's a command execute cycle forever.

      2. Exploration. Simply exploring a program, by seeing what it menu's contains, is a very easy, and intuitive way of exploring. CLI's have none of this.

      3. Rote memorisation. There is no motor memory when using the CLI. You must remember the syntax of commands 100% accurately. GUI's support "knowlegde in the world", as Norman puts it. Consider a door handle on a door, it has an obvious way of being used. Staring at "~$", is so very different.

      4. Easy reversal.

      In fact, the benefits of GUI's over CLI's are so many fold, I won't bother with digging out the literature.

      The command line has only one advantagde, it's speed, and the possibility of executing extremely complex commands. Both not things newbies are well known for.

      "To master modern GUIs, one must recall the operation, layout and relation to each other of hundreds, if not thousands, of such panels."

      Funny, I thought that was the same with CLI's. With a GUI, the GUI can at least support exploration of the interface. Click that arrow down, see what happens. A CLI can do none of these things, unless you consider adding random letters after a command, to be "exploration" ...
      • Re:Well (Score:5, Insightful)

        by martin-boundary (547041) on Tuesday March 09, 2004 @10:14AM (#8509222)
        Maybe in the beginning with windows 3.11. Unfortunately, times have changed. GUIs like WinXP are so complex and arcane, your points are no longer valid.

        1. State. With five windows open at the same time, four taskbar icons demanding attention, and background downloads and let's not forget Clippy, the state of the machine is so complicated to figure out it's impossible for a newbie. And then of course the state changes rapidly that it's not even worth figuring it out until you're a power user. for example, you accidentally click on another window and the whole current state is now with reference to the new window. That's hard.

        2. Exploration. Do I look for the command in the File menu, Tools menu, toolbar, right click context menu, shift right click context, properties panel under a seemingly unrelated program function, right click on the taskbar icon? What? By the time I've gone through all possibilities unsuccessfully, I might as well have typed several different commands at random. Same difference.

        3. Memorisation. With a modern cli, I have just as many reflex actions as with a GUI. Whereas I routinely right click on objects, I routinely press tab on the shell.

        4. Easy reversal. That's totally application dependent, and independent of GUI vs CLI.

        There's no "ease" advantage to GUIs these days, unless you consider locked down internet kiosks the paragon of graphical technology. Both interfaces are equally hard at the very least.

  • by ObviousGuy (578567) <ObviousGuy@hotmail.com> on Tuesday March 09, 2004 @09:19AM (#8508777) Homepage Journal
    But you think a command line would make using a digicam easier? A microwave? A thermostat?

    The computer as a non-specific device is a fundamentally flawed (though useful) contraption. The command line, GUI, and other UI creations are all hacks to help users get around the problem of genericity of the machine.

    As computers get more powerful and more 'intelligent', computer user interfaces like these will wither away and something more straightforward like controls for a camera, microwave, or thermostat become the primary UI of the computer. This means that innovations in computer operating system design must be made so that the OS can guess what the user wants to do and present an appropriate, simple interface.

    I really look forward to the day when the concept of the PC disappears.
    • by rduke15 (721841) <rduke15@nospAm.gmail.com> on Tuesday March 09, 2004 @09:39AM (#8508944)
      But you think a command line would make using a digicam easier? A microwave? A thermostat?

      I don't have either of those, but I often felt it would make the setup of my TV much easier:
      # move 14 15
      # move 28 14
      # tune 12 S25
      # tune 13 C35
      # describe 14 CNN
      # show channels
      ...
      14 CNN S25
      15 BBC C12
      ...
      ("S25" or "C35" being channels as listed on the cable provider's web site. Not sure if it looks similar in the US.)

      or my VCR:
      # record 14 today 21:05-23:00
      # record tomorrow 15:00-16:00
      Error: missing channel number.
      Usage: record channel date starttime-endtime
      # record 14 tomorrow 15:00-16:00
      But that will be easy when I replace my old VHS with a Linux PVR, I guess... (or will it?)
  • by Millennium (2451) on Tuesday March 09, 2004 @09:22AM (#8508803) Homepage
    I'd bet that the CLI is probably easier to learn for a complete newbie to computers in general, but a GUI probably easier to learn for anyone new to a given application.

    More intelligence in either interface would certainly be a Good Thing, however.
  • by AtariAmarok (451306) on Tuesday March 09, 2004 @09:22AM (#8508807)
    In my experience, the command line is more consistent, especially if you are telling someone to do something. Once you get into it, it just a matter of saying "press A, then press ., then...."

    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.
    • 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
    • I have made this point time and time again. Here's the steps in GUI and CLI of finding a file in a directory listing and showing it's properties:

      GUI
      1. Hunt around for and click on your file manager icon.
      2. The file you are looking for is called foo. It is in a subdirectory calld bar. Click on the subdirectory called bar in your home directroy (most file managers will put you there when you fire them up).
      3. Look for the foo icon. Right click an pull up properties.

      CLI
      1. Type pwd to make sure you are in
  • Interesting (Score:5, Interesting)

    by sniggly (216454) on Tuesday March 09, 2004 @09:23AM (#8508817) Journal
    When I installed a linux desktop for my mother about a year ago the trouble she really had was with the concept of the mouse and clicking. That the motion of the mouse in horizontal space translates into motion of an icon in vertical space, that a click OR double click means activation... She had to learn all those things and it took a while. The whole idea of icon and menu based computing was new to her and still isn't demystified.

    When she worked she worked with DOS based programs. I guess now these are so much easier to understand because you actually "talk" to the computer albeit through a keyboard and with a very limited command set. Maybe the mouse driven GUI is a bad inbetween step from the keyboard-only days to a time when computers understand conversation.

    One of the things I really miss when I sit behind a windows computer is a bash shell, tab completion, gcc, vi... and you usually arent allowed to install cygwin on people's systems :)

  • by Xpilot (117961) on Tuesday March 09, 2004 @09:24AM (#8508822) Homepage
    ...as part of its Win95 hype machine. Microsoft likes to point out that pointy-clicky is sooo much easier than the "arcane" and "cryptic" command prompt, and tried as hard as possible to hide it. Microsoft certainly didn't try to improve its command prompt much, and even in modern version of Windows it still retains a lot of its retardedness inherited from the early days of DOS.

    The question is, why? Sure, newbies hate it, but it's really useful to have a powerful command prompt, so it wouldn't hurt to include it. Even Macs have them now. Windows would be much more tolerable if it had a Unix-style command shell out of the box. Yet Microsoft feels the command prompt should die and it seems (at least from my point of view) that it's included only grudgingly in the OS.

    • by nickos (91443) on Tuesday March 09, 2004 @09:57AM (#8509077)
      look here http://slashdot.org/articles/02/12/29/1349230.shtm l?tid=109 [slashdot.org]

      An anonymous reader writes "I found this [jobsahead.com] while searching for Perl Jobs in India:
      "The Microsoft Next Generation Shell Team is designing and developing a new command line scripting environment from the ground up. The new shell and utilities, based on the .NET Frameworks, will provide a very rich object-based mechanism for managing system properties. To be delivered in the next release of Windows, it will include the attributes of competitors' shells (e.g. aliases, job control, command substitution, pipelines, regular expressions, transparent remote execution) plus rich features based on Windows and .NET (e.g. command discovery via .NET reflection API's, object-based properties/methods, 1:many server scripting, pervasive auto-complete)."
    • ...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...
  • True Story (Score:4, Interesting)

    by ellem (147712) * <ellem52@gmail . c om> on Tuesday March 09, 2004 @09:25AM (#8508833) Homepage Journal
    Had a Fujitsu laptop, like a P133, in 1998(?) and I loaded Redhat 6.0 and could NOT get the Xserver to work. I spent about 6 mos (now and again) at the command line putzing around on tryng to get the Xserver working. In that time I learned more about Linux AND Windows than I ever knew even existed. Suddenly alot of Windows oddities made sense... in the sense that I got what they were _trying_ to do. And it left me with a hollow feeling whenever I used Command... Why doesn't Windows have...
  • by pandrijeczko (588093) on Tuesday March 09, 2004 @09:27AM (#8508848)
    I developed an training course at work to introduce Windows-orientated users to Linux.

    From the word go I had them "cat"-ing, "sort"-ing, "grep"-ing and "cut"-ing files, showed them how to combine commands on the command line and how to turn them into shell-scripts.

    The guys I taught were, like me, support engineers on Linux-based telephony products and were keen on learning how to strip relevant info from log & text files.

    Within a couple of weeks they were churning out pretty good shell-scripts that were extracting info from files all across the system, "gzip"-ing them up and mailing them off automatically in cron jobs. Many of the commands they used in the scripts I'd never even mentioned in the training but had showed them about man pages and "find"-ing files on the system.

    The moral behind the story is that if you give people enough of the basics, they'll soon go find problems they need to solve and work out their own ways of doing it.

  • by MagerValp (246718) on Tuesday March 09, 2004 @09:31AM (#8508876) Homepage

    **** COMMODORE 64 BASIC V2 ****

    64K RAM SYSTEM 38911 BASIC BYTES FREE

    READY.
    #


    Now that's newbie friendly.
  • by Anonymous Coward on Tuesday March 09, 2004 @09:36AM (#8508914)
    Configure the DNS server address staticly:

    In windows:

    Goto start --> start --> control panel --> networking --> select the correct device --> options (or whatever I don't f-ing remember) --> select TCP/IP --> select options --> hit the DNS tab --> Select "I want to specify dns addresses bullet --> type in ip address in the boxes.

    Networking specifications are spread throught 100's of dialogs and wizards. Some can set conflicting settings, some can override the settings of others. Some are grayed out to prevent these conflicts and you need to figure out why. All system wide configs are stored in the same place as program specific configs and user configs. If any program or installer corrupts this one binary file it will render the entire OS unusable.

    In Linux (if the dns server is 192.168.1.1:

    echo "nameserver 192.168.1.1" >> /etc/resolv.conf

    Remember resolv.conf because DNS is to resolv the URL names into ip addresses. System wide configs are stored in plain text files in /etc/ directory. If any of these configs get corrupted you can edit them manually to fix them, or copy originals from packages, or copy them from another source and edi them to fit your needs.
  • by poszi (698272) on Tuesday March 09, 2004 @09:36AM (#8508916)
    I did some teaching of command line for non-English-speaking students and the biggest obstacle was the language barrier. They couldn't remember the command and they didn't understand the output of the command. Even if they knew some English, there were always some technical terms they couldn't understand and they felt intimidated. This way they were much more efficient in a localized GUI.
    • 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").

  • by Uggy (99326) on Tuesday March 09, 2004 @09:36AM (#8508920) Homepage
    from my web log, I think it's appropriate and strangely enough, quasi-religious...

    We all strive to be big monolithic programs, with fancy buttons, big memory footprints, environments where people, if they want to do anything, must go through us. We strive to be pre-eminent on the desktop, world stage. We crave fame. Look at me we say. Look how important I have become. I am an Office Suite, hear me roar. Look how much I can do. If you want to do any work, you must come through me.

    [snip]

    We must teach our brethren the ways of the Unix shell, for if we don't we will forever be trapped handcuffed in that big shiny plastic bubble of modern life, where we see but we can't interact. We must go back, back to the beginning and learn the first lessons.
  • ObOldJoke (Score:4, Insightful)

    by Ethelred Unraed (32954) * on Tuesday March 09, 2004 @09:36AM (#8508924) Journal
    Who is this General Protection Fault, and what's he doing reading my hard drive?

    That said, it would be rather helpful if command-line tools would actually communicate more in plain English. Most of the commands and responses were meant to save keystrokes and be brief, and were written by geeks for geeks (so to speak).

    Why write "Segmentation fault: core dumped", rather than, say, "Sorry, this program has unexpectedly quit because of a programming error"? In other words, worry less about technical accuracy in error messages and concentrate more on making the computer and OS more understandable to non-technical people.

    I'm not saying bash or the other shells should be re-written that way, but it would be nice if a more newbie-friendly CLI was around.

    Cheers,

    Ethelred

  • by arevos (659374) on Tuesday March 09, 2004 @09:37AM (#8508927) Homepage
    Interestingly enough, I'm designing a shell for my final project at Uni. This is a pretty useful article, all considering. I was originally designing the system to be more easy to use for powerusers, but perhaps there's a niche for newbies too.

    Before, I was concentrating on the syntax of control structures. Like having:
    if ($value == 1) { echo hello }
    for $i (1:10) { echo $i green bottles }
    Rather than:
    if [ $value -eq 1 ]; do echo hello; fi
    for i in `seq 1 10`; do echo $i green bottles; done
    I could think about adding in a better help system as well. I've got a few months left of design work.

    And I need to fix the lexer, too. In a recent presentation, I found a rather embarrassing bug. The concatenation operator in my shell is the same as perl's, the full stop, or period, ".". Cleverly, the shell can also treat numbers as strings and strings as numbers.

    Unfortunately, it was all a bit too clever.

    The expression 3.0 + 2.0 was parsed as (("3" . "0") + 2) . "0"). Giving 320. Oops!

    But given a little more work, maybe I could get it to solve some of the problems mentioned in the article above. Could be an interesting thing to do.
  • Ease of Use (Score:3, Interesting)

    by 16977 (525687) on Tuesday March 09, 2004 @09:40AM (#8508953)
    When I was a kid, my parents had a DOS-based computer with an early version of Quicken and a text editor that they used to write letters. Now they have a newer computer that runs Windows XP, but they still prefer to use the older programs.


    If I was to teach someone Linux, I would definitely teach the command line first. When there are just a few programs you use, it's easier to memorize their commands or keyboard shortcuts than it is to hunt through a menu each time. E.G., if all you want to do is play Pac-Man, you can either a) Hunt through the menus to launch gRustibus, wait for it to load, scroll through the gamelist until you find the right version of Pac-Man, and double-click the name, or b) type "xmame pacman" at the command promt.

  • by Gothmolly (148874) on Tuesday March 09, 2004 @09:41AM (#8508959)
    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.
  • by dpbsmith (263124) on Tuesday March 09, 2004 @09:45AM (#8508983) Homepage
    The pity is that GUI usability peaked sometime in the late eighties and has declined since then, as the rise of "computer literacy" has created an expectation that users will master complex UI's, and the rise in computing power has removed any barriers to marketing-driven featuritis.

    The most telling point was the discussion of "discoverability." "Discoverable: The interface must, from first switch on, provide a clear direction for a new user to go. At each stage it should encourage experimentation while providing adequate notice of important or key features."

    In the 1980s, GUIs were intentionally designed to facilitate discoverability were far more "discoverable" than CLIs of the day. They were also intended to be forgiving. The user was supposed to feel empowered to try things, confident that there was always an "undo" to bring them back. On the Mac in the 1980s, "Undo" was far more prevalent and worked far more consistently than in today's software, in which many operations commit you to something whose effects you may not understand.

    As for "dialog," UI designers understood that well. Why do you suppose that what are now called "screens" were once called "dialog boxes?"

    What the article is really saying is not that CLIs are better than GUIs, but that a) modern UIs are not catering to the needs of the average user, and that b) modern UIs have gotten so badly designed, cluttered, and complex that they have become less usable to beginners than CLIsbecause GUIs have deteriorated, while CLIs have benefitted from benign neglect.
  • by Lewisham (239493) on Tuesday March 09, 2004 @09:55AM (#8509059)
    This is certainly a very interesting idea, and has good points to it. I would hazard, however, that the CLI is most definitely not the way to go to get new users up and running with computers. The author is almost there in his article, but doesn't seem to make the leap...

    Using the example that the author used, he says Tilly multitasks, but doesn't do more than one thing at once. When she wants to leave something for later, she puts it to one side. This is an almost exact description of minimizing windows. It isn't suspending programs, or moving them into the background, like UNIX. It's just putting what you're doing out of the way for the moment.

    Tilly goes to the grocers and tells him what she wants. Why not point at what you want? I want my mail, click the big envelope. I want to type something, click the Word icon.

    It's arguable that some of the easiest programs that run in a terminal are those that are like GUIs, just without the mouse. Pine is a perfect example. It has labelled buttons at the bottom, except you interact with them using your keyboard instead.

    GUIs are still the best way of getting general users interacting with computers, it's just certain elements of GUI design that scares them witless. Working on a helpdesk for my University residential network, I reguarly hear what could almost be called fear in a voice when a dialog box or something pops up that I didn't expect, and warn the user was going to happen. GUI design is very imperitive. Boxes appear saying "DEAL WITH ME NOW" and giving themselves the utmost importance. This is what scares people. They think that because something took the time to alarm them in such a massive way, something amazingly bad must be happening. These windows often pop-up from applications that aren't being worked with. By preventing these, everyone would be a lot happier. The Mozilla new mail notification is an absolutely excellent way of telling the user something is happening, it pops up in the corner, says there's some mail, and disappears. It doesn't ding. It doesn't grab focus. It doesn't appear in the middle. It just gives you a quiet hint.

    GUIs are also far too ready to boot up programs of their own accord. When users get notifications from something they didn't run explicitly, they get the fear. CLI doesn't do that, it only shows you output from things you've done.

    The author says that users are scared to click buttons, in case of something going wrong. But they feel that a CLI can't do any harm. Users *do* want to point and click their way around buttons, and GUIs do complain of something wrong in essentially the same way as CLIs. Maybe it's because they have no visual feedback when they type sudo rm -rf / ? I think it's just a residual fear from the constant shouting that current GUIs do.

    GUIs are currently too noisy, and the essential quietness are what these users are responding to. I would hazard that as soon as the users want to do something more difficult (that would need a pipe), they'll be desparate for a GUI interface instead.
  • by WWWWolf (2428) <wwwwolf@iki.fi> on Tuesday March 09, 2004 @11:34AM (#8509965) Homepage

    Ever tried telling people on phone how to do a task in Windows?

    "Click Edit, Options, and... err, wait, yeah, Page settings, Margins..." (5 minutes later, or 10 minutes if you don't have the same program in front of you) "Wha? I told you to click on OK, not Cancel!" (10 minutes fly by...) "So it doesn't work? What do you mean there's a setting like that? Why didn't you say so? I'm deaf and stupid. Sorry."

    As opposed to:

    "Just type '/sbin/ifconfig ppp0'. ...Wha? that's 'slash-s-b-i-n-slash...'" and a moment later "So it isn't even connected. Right. Try typing 'pon'."

    The GUIs may be good to work with, but CLI is easier to explain. Especially if you're used to doing GUI things in one way and others do it the other way.

    GUI is like a religion - you "learn" it, and only you can explain what it means to you. CLI is like science - you learn it, you can explain it, and it means the same thing to everyone - except people who argue about "useless uses of cat(1)" and proper order of parameters, and whether to use sed(1) or perl(1), of course.

    And now I need the freaking coffee already.

You can measure a programmer's perspective by noting his attitude on the continuing viability of FORTRAN. -- Alan Perlis

Working...