Slashdot Mirror
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."
Does anyone remember 4Dos? Between that and Qmodem, I learned a whole lot about computers.
Life is the leading cause of death in America.
I have always wanted to bind my run line into the start bar of Windows XP....
It has been my experience when trying to improve efficiency, the mouse has been a pain. Using it to click and move around a mouse pad may be easier, but the time it takes to grab a mouse and move it could easily be beat by pressing tab and enter.
give a newbie instruction on how to operate a computer with 1's and 0's they will just as easily become apt at it.
These days people only know the GUI, for that matter the MS Windows UI of doing things. Most people have no time/reason to understand how things work or that there is a more optimal way of doing things. The other guy watchs TV so, I must watch TV. Get it.
I write diagnostics tools for a living. All command line based. Same source tree compiles on Solaris, Win32, Linux, NetBSD, FreeBSD, AIX and MacOS-X.
Too bad, users of MacOS-X are the *only* ones who need handholding to operate the tools.
To Terminate, or not to Terminate, that's the question - SCSIROB
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.
I have been pwned because my
The thing is, I found windows to be far superior in using the keyboard in GUI applications. You can navigate completely without a mouse in Win XP something you really can't in KDE or GNOME.
I also frequently use the start->run command, I never manually browse to a folder.
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.
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.
Don't blame Durga. I voted for Centauri.
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 :)
Of those to whom much is given, much is required.
My dad is all of 64 yrs. When he started on computers a year ago - he started with Linux (the man does not know the "windows-way". One of his early observations was that it was easier for him to learn the command line and keyboard shortcuts. He could list these on a peice of paper and run thro' whenever he ran into trouble/forgot. Of course now he is on KDE 3.2 and seems fine with the GUI...
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...
This
It may be more logical,
but it's more memory intensive - visuals are easier to remember. Well, I find it easier to remember visuals rather than words.
A blog I run for the wealth
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.
Gentoo Linux - another day, another USE flag.
All I can say is that I am an old school MS-DOS guy, and it constantly drives me nuts when I see people using Windows Explorer to find a file, select it, go to the menubar, select Edit, Copy, and then navigate to a different directory in Windows Explorer, menubar, Edit, Paste.
Maybe it's because I type 80wpm (at least when doing sysadmin work in MS-DOS I do), but things I do in MS-DOS seem to take 50-75% less time than to do similar tasks using a mouse & windows only.
Check out the best P2P sharing website: MEDIACHEST.COM
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.
Save the bandwidth. Don't use sigs!
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"
Before, I was concentrating on the syntax of control structures. Like having:Rather than: 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.
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.
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.
Designed for Women.
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 it. I don't want to have to troubleshoot it every day. I don't want to have to wait 10 minutes for a reboot. I don't want to have to install patches 5 times a week. I want to turn it on like a TV and play a game. If I need more space, give me a (literally) plug&play harddrive that's no more complex than a flash card. I don't want to open the case and muck around with IDE cables and jumper settings.
Ok. Enough ranting. I'll go back to work.
look here http://slashdot.org/articles/02/12/29/1349230.shtm l?tid=109
.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)."
An anonymous reader writes "I found this 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
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
Two wrongs don't make a right, but three lefts do.
> Command output is problematic since users often expect feedback. For
:\\\); else echo :\\\(; fi\`\\\$ "
:) on the prompt if the previous command succeeded, :( if it failed.
> 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
This puts a little
and a
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.
On a Unix system, however, there's just directories, executables, and arbitrary data files (yes, yes, and special files to be found in /dev and /proc). You would expect a certain set of commands available to find your way through the file system, but already the shell comes in a gazillion of flavors.
So I don't think Joe User would benefit from such an ncurses thingy which blasts tons of commands into his face...
But maybe there's an ncurses version of xman?
Amen to that. Yesterday I was trying to explain to our HR director why copying-and-pasting a 114-page document in Word was devouring his memory, but "copying-and-pasting" the same file was handled easily. He's a pretty smart guy, but he's been dumbed down by GUIs.
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 type "cd a" and hit TAB I want the first directory beginning with 'a' not, the first file. If I type "gpg --list" and TAB it presents me with "--list-keys", "--list-secret-keys" as possible choices, so I type "gpg --list-s" and hit TAB again and it correctly fills out it out to "--list-secret-keys". And so on.
How would it do this? Well a command could ship with command template file that says how to expand the argument the cursor is on when TAB is hit. Bash would use that template to determine what to do and if there were no template it would fall back to its default file expansion behaviour.
It would make using the shell a hell of a lot easier and more interactive than it is now.
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.
Infuriate left and right
I patched the find man page with some examples and submitted my diffs to the find maintainer a few years back, but they don't appear to have found their way into the man page. That's too bad because the syntax for -exec is not intuitive to a newbie and one of the questions I'm most frequently asked is how to use find to operate on files.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Autocad is probably one of the most complex applications that I know. But the one thing that they've done right over the years is preserve a command line that gives you total functionality, along with a history to show you what you did. You can click and drag your way through a design, or you can type it in at the command line and then selectively move items with the mouse *if* you want.
It also reinforces your understanding of the commands to the point where the dialog boxes are merely pretty wrappers and you know exactly what you're trying to do, instead of getting wrapped up in the position and naming of items to click.
The command line also reinforces concepts and a deeper understanding of what the program is designed to accomplish (with Autocad, designing objects). Try as the designers might, you can always get into an argument that this menu item belonged here, and this dialog box doesn't make sense, etc. etc. With a command line in the program, I simply ignore the arguments and get work done.
I'm not sure why nobody's picked up on this yet, probably the horrible must-work-in-a-ssh mentality. Sure, people who can ssh in can use man -k. But for the rest of us, typing in an xterm or similar, the original Mac programming environment - mpw - had the best method by far of helping someone on the command line.
... and a dialog box popped up with full-on gui goodness to let you enter the command. While you were chaning the options, it wrote and rewrote the exact command line you had to use in a pane at the bottom of the window. Genius.
It was called Commando, and if you couldn't remember a command's options, you could type it, press apple-enter (IIRC)
It turns out that companies like Sun and IBM have researched this before. The results they came up with is that the new users found their way around and accomplished tasks faster with a GUI interface, but were more likely forget by the next time how to do it. With command line, it took a while to learn it, but then the retention rate was higher. The research, I believe, the systems used were running Solaris/AIX respectively with their X Windows vs. the command like on the same systems.
Like you said, theres a certain set of commands available and most distros just default to bash anyway.
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.
The implication of the article is that GUIs are a mistake of monumental proportions. All of the original testing at PARC and Apple were fundamentally flawed and the computer industry has blindly charged ahead on a false conclusion.
The fact that the author of the article had such success teaching the command line almost certainly more a tribute to his teaching skills and enthusiasm than virtues of the CLI. There's no question you'll learn more about using the computer from a good teacher than you will from GUI.
The irony that using a GUI is necessary to read his article should not be lost. Even reaching the article from a command line would have required typing in a 41 character url with no errors.
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.
:) Then again, someone probably already has.
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".
-=fshalor
I think GUIs and the CLI both have there place. However, undoubtably, the CLI is simpler, faster, and more powerful in certain circumstances.
Just recently, a colleague (running Windows XP) and I (running Linux) took our laptops to a computer lab providing IP addresses via DHCP. My colleague, after spending literally 20 minutes fighting with his GUI receiving ambiguous error messages and having the OS seemingly do the exact opposite of what his intentions were, finally gave up. Some setting, hidden in XP, was refusing to let him use DHCP and insisted on trying to connect to his usual ISP.
On the contrary, after 3 seconds editing a config file, I confidently typed "/etc/rc.d/network start" and, as expected, had instant network access.
I think this is a simple example of the many (not all) areas in which the CLI is simply superior.
Simple little script to figure out what a command does. Works on most of them. Keeps me from having to do a "man [command]" just to see what it does. It's just something I put together in a minute, so forgive me if you don't think it's done the right way - it works quite well for me. Feel free to use it if you like.
; ;
#!/bin/bash
test=$1
if [ "$test" = "" ]
then
echo " desc - Short for describe. Display a one line description of what a command does."
echo " Usage example:"
echo " desc ls"
else
if [ "$test" = "desc" ]
then
echo " desc - Display a one line description of what a command does."
else
man $test | grep "$test - "
fi
fi
Find a job you like and you will never work a day in your life.
one single page shows up, gives all relavent info
And unfortunately, all the irrelevant info as well. Reading through a lot of manpage is truly soul-destroying, and it's hardly a surprise that they're not too popular with newbies. Try man cvs or man gcc if you don't believe me.
== Jez ==
Do you miss Firefox? Try Pale Moon.
Although I'm only 21, I grew up in a DOS, and, later, a Linux environment. I still prefer vi and vim to VS.net. I was using a Windows program a couple days ago, and it wanted the folder to rip music to, I went to type in the folder (q:\.......\music), and it wouldn't let me. When I realized that I would be forced to use a GUI folder selector for each of the three paths rather than copying and pasting, my heart sank: I realized just how horrible the world has gotten when even programmers expect me to use GUI for everything. My point is, a lot of us grew up on command line, and we turned out great. A lot of people grew up on windows xp/msn messenger, and I can't help but look down on them. When I say, "Your 40gb drive is full of spyware and installed programs/partially uninstalled programs/whatnot, it's time to format" they say, "huh?" because they aren't famalier with core computer concepts. When I was forced to learn what IRQ and DMA meant, and I had to use mscdex when I was 10, I ended up better for it. I understand how the machine works, and I am much happier for it.
http://www.skullsecurity.org/blog/
At the youngest ages though a GUI interface is surprisingly intuitive. I found this out when my 18month old began clicking on things. He'd click on an animal, say it's name or make the sound.
At 19 months he's playing Concentration (memory) on a game called Childsplay (available through sourceforge).
Childsplay is a pretty cool progam made to add different modules. Some of the modules though have default words like: sister, baby, fish, linux. It receives my vote for having the best penguin in a diaper.
t
1) CLIs have state too. If there's a prompt, the computer is waiting for your input. If there isn't a prompt, the computer is busy doing the last thing you told it to do.
2) If you want to explore, RTFM. The idea that a tool and its documentation need to be integrated doesn't make sense to me -- do hammers come with a "how to drive nails" pictorial pasted to the handle?
3) There is certainly motor memory involved with CLIs; you use motor skills in your hands to type, don't ya? After years of CLI usage, frequently-used commands such as `ls -l` flow from my fingers without conscious thought. My fingers have typed that string of characters so many times, it's imprinted in motor memory.
4) Easy reversal requires conscious effort on behalf of the software designer, whether it's a GUI or CLI tool. It's not a design consideration that's endemic to one or the other.
Oddly enough, since I started my webhosting ordeal, I have found that complete and utter newbies ARE oddly good at picking up the command line.
:)
For example, I walk most first time customers through the usual setups, SCP client, SSH client,Mail, all that depending on what OS they are on.
I swear, it takes me three times as long to walk them through the GUI stuff, with all its bells and whistles they have to think about.And then the 'hard part' of the command line, they are off and banging away within a few short minuts. In fact, I have had a few newbies take one look at Pine and go 'Oohh, neat, I don't even need a program to use it!'
AND THEY USE IT(pine)!
And you have no idea what I mean when I say 'newbie', I mean literal 'Just got away from yahoo webhosting, does not even know HTML yet' newbie. Picked the command line right up, and yet I got two more calls for the damn GUI client. And this is hardly the first time.
Sometimes I really love this line of work..
My new top secret key -> C>N|KB
I was an operator/admin on an archaic Wang 300 mini system back in the 80's on a US air force base. The OS was Wangs multiuser system and, while fantastically old by todays standards, demonstrated something that I not seen in later jobs as admin for on Windows and Novell systems: consistency and simplicity.
The user had access to Wangs text based word processor, spreadsheet, groupware and simple database programmes, of course everything running on a central system and the users only having terminals.
There was far less, and I really mean far less support hassle, especially on the telephone as it was so much easier to understand what the users currently were doing and the users, having a reduced set of commands, could mess up in x number of ways. Added to that the interfaces were consistent and easy to remember. Ironically, all that could today run on a single Unix machine with terminals with ease (about 150 users).
I compare that to the aches of supporting Microsoft office in my last jobs, with users being all over the place and repeatedly not being able to remember the simplest of GUI functionality. Not even younger employees who had grown up with GUIs were confident in what they were doing.
The comment about graphics is valid though. A hybrid CLI with graphics functionality would probably be the best bet for all.
..anybody who uses an OS X box regularly knows what i mean. a well-designed GUI makes a lot of tasks simpler - i know a lot of you like your config files, but i really enjoy my mac config dialogs; you're absolutely nuts if you want to argue the firewall (in OS X) is easier to set up from the shell rather than system preferences. OTOH, i do use iTerm rather a lot, especially for dealing with huge quantities of files (Aqua bogs horribly when you try and move >2000 files around at once) and non-graphical web stuff...FTP is literally about half again as fast from the commandline. basic text editing too, although bbedit's multicolored highlighting with programming languages is nice for certain things.
side story: my dad was a communications operator for the air force in 'nam, a guru of the proto-net - he used to tell me about playing battleship with people in Greenland, in 1968, over the teletype. he hadn't touched a computer in 30 years, loathed the things, until i sat him down in front of my box, logged in as >console (switches off Aqua, drops you to a pure CLI). he stared at it for a second, then his face lit up as he said "OHHHhhh, it's just like my teletype, only on a screen!"...he's now does all his email, web browsing, imming, and text editing (invoices, inventories, whatnot) off the commandline. he DID ask if i could use the printer instead of the monitor once though, i had to shoot that one down...
Facts do not cease to exist because they are ignored. - Aldous Huxley
As for the user, if I sit down at a computer that is localized in French, I can still use it because we all agree on what the command names are, regardless of what language we speak. "cd" is not "change directory," it's the mnemonic for the command that changes the directory. I don't care if it's zk or zmienkatalog, so long as it's the same. If I want something else I can alias it. By way of example, I logged into my normal account using Croatian as the localization context. Everything works as expected, but I can't read the error messages.OK. Let's see what languages are supported on this machine.
No problem. English, Japanese, and Croatian. My Japanese is not much better than my Croatian, so let's try English.
Oh... that wasn't too bad. Let's just set the language for English from here on out though.By ensuring that all the commands and protocols are the same, Japanese, Croatian, and English users of this machine can all use the same programs, and most importantly, their programs can interact as well.
-Hope
"I think the person doing the alias to man -k is the system administrator... | ... Ah, the "local customization" myth. This may have worked back in the day"
I think the person doing the alias to man -k is the distro maintainer
"look, I typed la and it did an ls for me! And it works when I type dir too!" [mandrake newbie]
I've TA'd a few 2nd-year CS courses, and I've noticed that even the most primitive CLI-proficient users are leaps and bounds ahead of the most advanced GUI-adept users when it comes to understanding the fundamentals of computation. CLI users are quite familiar with things like turing machines, because much of what they do behaves in a similar fashion. GUI users can't do anything without triggering events, dealing with multithreading, etc. It's so complicated they don't really know where to start when we make them build them themselves for the first few times. Our department has a few low-level classes that emphasis GUI-based programming, and a few that emphasize CLI-based programming. The students love the CLI, because, get this, it's a simpler and more intuitive way of doing things.
Granted, the average newbie and the average starting CS undergrad are a little different, but I've definitely witnessed the phenomenon at work.
WARNING: there is a trojan on your
That was my exact thought the first time I used a *nix at school. To me it looked and acted just like DOS and like a lot of BBS software I had used but if you wanted to do something rock-bottom-basic like read email or edit a file you were fucked unless you had someone to show you.
I remember thinking even the absolute worst software I had ever used had a "help" command, and most commands made sence, but on this less-than-intuitive system I had to type in assorted tree species instead of "mail" to read my email or type in a nonsence word like emacs or vi if instead of "edit" if I wanted to edit a file, etc. etc..
Even the most absolute, brain dead, rock bottom basic command was obfuscated. For instance, if you want to change your password, do you type password? No. Maybe it's abreviated to pw? No.Pswd? No. The second half of the word is half abreviated, but not the first half. What fucking idiot came up with that? Oh, and for shits and giggle some genius made the command line case sensitive.
I think back to that day every time someone tells me Linux is just about to take over the consumer market.
In my experience, I see that newbies get along better with the CLI than with the GUI. Perhaps this is because they "know" the CLI is hard, they pay attention, but because they "know" the GUI is easy, they think they're stupid when it's not.
But another reason is that GUIs have an infinite number of states, whereas when he see a command line prompt, you know exactly what state the system is in.
I gave me parents my old 8086 running DOS. They had no problems with it. When I told them what to do, they wrote down the instructions step-by-step. Now my mom has a Windows system, and she's as confused as I've ever seen her. I can't give her step-by-step instructions, because one can never know the exact state of the system to start from. If the order of the menu items change she gets lost. If she installs a new program the icons on the desktop change position and she gets lost. I've even had her accuse me of breaking the computer when I forget to remaximize the Internet Exploder window after I was done using it. Since it wasn't maximized she didn't recognize it, and wanted me to put the system back the way it was.
It took her the longest time to realize that the purpose of moving the mouse was to reposition the mouse cursor. For a while she was wondering why moving it two inches to the left and clicking didn't always bring up the menu.
My mother is not stupid, she just hasn't groked the underlying, unwritten and unexplained paradigms behind the GUI. She doesn't think of the computer as something to interact with, but as a machine you issue commands to. Hmmm, she is pretty smart after all...
Don't blame me, I didn't vote for either of them!
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.
Oh wow, does that bring back memories...
;-)
If there is one thing that DEC did better than just about any other company before or since, it is this: They knew how to write good documentation. The HELP command in VMS is a sample of what they did.
However, if you really wanted an even nicer CLI, try another OS from DEC: Twenex --I mean TOPS-20 (Send me a message if you know the history behind this).
Instead of Tab completion, they used the Escape key. I think the first place I ever saw auto completion was on a TOPS-20 system (Version 3, IIRC, and it was a long time ago). I have always liked auto-completion and I've always thought that it would make a comeback some day.
Meanwhile, grizzled old command line users like me have always found command lines to be places where we could get "real work" done. (What? You had command lines? In my day we had front panel switches, incandecent address and data lights, and paper tape readers!)
Given the overly rich and confusing numbers of icons, sounds, popups and flashy widgets on screens, maybe a minimalist approach to computing might help people understand what's going on. This industry often tries to make too many concepts in to abstractions. Perhaps it's time we went back and rediscovered our true hardware
Nearly fifty percent of all graduates come from the bottom half of the class!
Does anyone else here remember the "why" command from AmigaDOS. After a CLI command failed, you could type "why" and it would give you a long 'human-readable' explaination of what happened.
But you did so only for *your* boxes. Now think of a user in your company who got around to installing Fedora on his home box: "Huh, none of my neat office commands work! crap!"
Your changes are not portable. They do not show up in newbie mailing lists, LUG meets, books. For the vast world outside, your changes are not useful.