Slashdot Mirror
The Case Against GUIs, Revisited
snydeq writes "Deep End's Paul Venezia advocates the importance of the command line, in light of the increasing use of GUIs in today's technologies, as well as the increasing perception among admins that proponents of the CLI are dragging computing back to the 'dark ages of the C:\ prompt."
I use Linux specifically for the powerful Bash-fu.
... speaks more of the admins who assume that "CLI" == "C:\ prompt".
Or the idiots who think "CLI" == "the GUI in front of me is therefore made unusable". The people at "GUI Industries" can't make a link or shortcut to the appropriate script?
Why would you trust an admin who can't, as TFA indicates, edit a text file?
This is dead on. Human beings invented symbolic language because it's simply more expressive than pointing and grunting. CLIs are superior to GUIs for the same reason.
Give me Classic Slashdot or give me death!
I'm afraid I can't let you do that, Dave.
There's no -1 for "I don't get it."
I haven't used windows since '99.
looking around my desktop right now, while posting to slashdot, I have chromium running, and 7 xterms. Two of'em are running irssi, the others are just nice little windows to do various bits of work in.
I live and breathe in a CLI environment. I can't really remember doing much useful in GUI's except lookup information (for which it's suited perfectly well).
But why on earth would you do configuration in a GUI? Why would you ever program in a GUI, instead of vim or emacs?
I just don't get it.
"Rune Kristian Viken" - http://www.nwo.no - arca
CLI is not essential. It's a holdover from a time when we thought words were a good way to express function. And then left the 'e' off "creat" for kicks.
Everything can be done in a GUI. I don't see why not. We just haven't made that happen yet.
I can back up the claim that the CLI is making a huge come back. I run a feed on twitter and identi.ca called @climagic that is becoming very popular. I think that people are trying to find ways to do the things that they need to do in GUIs and when it can't be done, they find that it is easier to access and manipulate your data using Unix command line tools in very efficient ways. Does that mean that its great for everything? No of course not, I'll admit that I use the GUI for many things too, in fact, I do graphical work in Blender and Inkscape and listen to music in Pandora and do my browsing in Firefox because it works well for me, but in many places, I can get my work done using the CLI and still wow people with iPhones and Androids in 2011.
Well of course nobody wants to continue to use a Windows CLI, it IS from the dark ages.
The spoken word is just an auditory CLI. We operate those around us via commands (and requests, and interrogatives, but you get the idea) every day. I expect you'd find it quite unusual if someone tried to get you to do something just by pointing and clicking.
Give me Classic Slashdot or give me death!
Some UI may go this way eventually, but I imagine most written/typed communication is still incredibly valuable.
I imagine it won't be long before we communicate with computers very much the same way we do with people.
For casual simple tasks, that means mostly voice (which computers suck at today) and a bit of gestures (which computers are OK at with a mouse).
For anything complex, though, communication between humans is typically written - and I expect it'll continue to be so for computers for as long as people interact with them -- not because it's great for the computer, but because it's the best humans come to a high-bandwidth precise recordable communication channel.
They must have an incredibly advanced command line parser on Star Trek ships.
There's no -1 for "I don't get it."
GUIs are great for repetitive, predictable functions and data visualization.
CLIs are great for ad-hoc processing.
People who need a GUI to do complex processing of a one-off chunk of data are just as incompetent as people who set up a text-based way of monitoring a 4000 node network. They're tools, people, the screwdriver will NEVER replace a hammer.
A command line is more flexible than a GUI could ever be. It just has a steeper learning curve. Since computers are more mainstream these days GUIs are more prevalent. That doesn't decrease the value of command lines though.
except that software should be accessible by design, and GUIs have issues for blind people.
The frustration of doing this was foreseen by some of the writers of Star Trek. If you watch some TNG episodes where Geordi interacts with the computer, you'll see him getting frustrated with it not understanding what he wants. I always felt that Geordi was a lot like an IT engineer of today.
We may be able to talk to computers, but I imagine it will be very hard to get them to the point that they understand each of our individual expectations. Even once we think they are comprehending, they still won't.
I'm not sure if this is the case, yet it seems GUI layers of garbage introduce a layer of viris vulnerabilities. CLI, I'm game with it.
cmd.exe is a terrible shell. The new Powershell Microsoft has is pretty nice. I like it more than Unix shells. I find passing objects between commands to be easier. Now Microsoft just needs to dump their console.
Anyone who thinks that a command line prompt starts with a 'C:\' has no idea what they're talking about.
Systemd will do more to rub out the use of the command line than any thing since the gui. The author has decided for every one that applications should be able to figure every thing out for themselves and passing switches and arguments to them is archaic. This will remove the incentive for application writers to bother adding interfaces to applications that will alter their functionality. That will give us fewer reasons to use the command line. It is a vicious circle.
I'm in the middle. I like GUIs for a lot of advanced program usages that I haven't learned on my own yet, but, for example, I've never found a visual DNS utility I liked. They're all just too slow. Classic (read: non-AJAXy) Web Interfaces are worse. Maintaining a router via it's built-in web server is antagonizingly slow.
Having said that, most everything else I do is all command line work.
The idea that people have to be on either side of the fence is almost as ridiculous as there being a metaphorical fence to begin with. I use a desktop OS (Windows 7) and I love cygwin, which I run in Console2. The two can be used together, you know. There's no need for it to be a black and white discussion -- only useful for making one seem 1337 or 'in the know' and bicker like tools. We have both -- why not love both?
Truth, Just Us, And Hatred For All Mankind!
Hence why they came up with Powershell, which I have to say is rather good, and many Server 2008 tasks demand a basic knowledge of it.
Hell it even has grep (findstr), though sadly it hasn't go a worthy sed substitute.
For all intensive porpoises your a bunch of rediculous loosers
While the C:\ prompt would really be the Dark Ages all over again, command lines done right can be significantly faster to use for experienced admins. Not to mention they can also be used in diverse interface environments like serial connections in almost exactly the same way that they are used anywhere else. It's significantly easier to script from the command line as well.
Just about every shell available on a UNIX-like OS is at least ten times better than DOS ever was. Lumping in bash with DOS is like taking a BMW and saying it is equivalent to a Yugo because they both have four wheels and an internal combustion engine.
There's certainly a place for a GUI, and well designed GUI apps are lifesavers in big environments where seeing a graphical representation of 1000 servers as icons and being able to click and drag to select and execute group commands is a much easier way to work with that many servers. Having 1000 lines of text zoom by is going to be hard to take in at a glance. I love the GUIs that I use for certain tasks like visualization and management of complex environments.
Still, anyone who considers the command line to be the Dark Ages either doesn't know how to type, doesn't understand how to use a CLI, or is simply trying to sell you a pretty GUI app.
that the new ubuntu start menu has a part when you can run programs... by typing the names of them!
because scripts don't work
thank God the internet isn't a human right.
With shell scripts, you can write your own menus.
Dilbert RSS feed
Interestingly, I had to put little watermarks on about 400 images a year ago. It took about 5 minutes of scripting with ImageMagick to do it.
If I'd done that with Photoshop or GIMP, I'd still be at it!
A picture (GUI) is worth a thousand words. Why use a thousand words when one or two CLI words will do?
GUIs are, in fact, essential - without them, slashdot would not exist.
GUIs are useless at performing repetitive tasks. The emergence of PowerShell on the MS platform in the last few years means I can do stuff that was previously impossible to do - maybe throw user objects around between AD, SQL Server and SharePoint. Heck, even the GUI tools are based on top of the PowerShell commands.
In fact, PowerShell is one of Microsoft's best moves, and something that has sorely been lacking from the Windows platform for too long.
CLIs are also really good for:
1) Configuration differences
2) Compliance logging
My company (www.uplogix.com) makes a device that does these two things for a wide range of advices. It's pretty damned useful. And it doesn't rely on the GUI maker adding useful logging of each step done in the GUI. You have the text session. You know exactly what the user did.
As an avid CLI user on *NIX and Windows I would vehemently object if I was dragged back into the "dark ages" (aka 1980s). It seems that as soon as you mention CLI this is what people bring up for an argument. I suspect these are the same people who have not taken the time to objectively evaluate a modern CLI be it bash or powershell or something similar.
I humbly suggest these are the same people who have never had to log into and click away on a GUI to configure an option because the package does not have any CLI support on 30+ machines. Don't get me wrong, GUIs are great for a great many things but there are many tasks where a good script and a command line beats the GUI hands down. A simple example is turning 70+ machines over in a computer lab to put them in a special "exam state". With scripts and command line this takes literally less than 1 minute to hit all machines. Now I suppose if you had some nice admin tool GUI that allows you to point and click to select a set of actions to perform on each machine or group of machines you could achieve the same thing but I have yet to see it.
Goddamn, you can tell this is a site for geeks. People who use command line are about 1% of people who use computers. The reason we all have jobs is because so many people use web sites and software these days. The only reason so many people DO use websites is because they DON'T have to use command line!
America, Home of the Brave.
The difference between a GUI and a CLI is that a CLI rewards understanding with capability.
GUIs are appropriate to non-expert systems where functionality must be patently clear. Think of your smartphone / PDA, or a consumption-oriented computing device (iPhone, iPad, PowerBook).
If you're administering or creating content, you'll eventually want the power of a real scripting tool.
for scripting things there is nothing like the CLI. only thing i have seen even close is automator on macs
What do you mean "C:\ Prompt"? Did you mean the "bash-4.1$" prompt?
Command lines discriminate against those with poor memories. GUIs make it possible for people who can't remember detailed shit to be productive without having to constantly refer to some other resource(s).
I learned English well enough that I rarely require a dictionary, but I was never so lucky with programming languages and other syntaxes. I love my GUI... when it's implemented correctly. Paul Simon wanted his Kodachrome, and I want my GUI.
Why does this always have to degenerate into a Campbell's Chunky Soup "Fork or Spoon" debate? Why not just use the most appropriate interface for the task at hand?
A GUI can be shit for some things, and (unless you live and breathe CLI) a CLI can be too complex and unwieldy for other things.
Does it make you happy you're so strange?
This is not really about Linux vs. Windows, as both of them have GUI methods and CLI methods for accomplishing this task. It is more about GUI admins vs. CLI admins.
If you don't know where you are going, you will wind up somewhere else.
All tabs, one after the other? Every single config page called out from a tree selector in a sidebar? The pages that scroll - carefully scroll each one in turn and make repeated screenshots? You're practically guaranteed to leave something out. Then to recreate the same config on another system what do you do? Repeat the entire exhausting process in reverse? When you're done, you're practically guaranteed to have errors because the entire process relies on a human doing tedious work that a script should be doing perfectly every time.
A config file that differentiates between tabs and spaces is an inexcusably badly designed config file. It says nothing about a weakness of the CLI.
A GUI is really awesome if you want see different information from different sources, and make specific actions that cannot be automated.
The two of them need to coexist - use the best tool for the job, which could be either a CLI or a GUI.
Guns don't kill people, "with glowing hearts" kills people.
Why not just have both? Lets take apache httpd.conf for example. Someone who's good at CLI can whack that open in vi/emacs, jump down to the line they want and change an option, or write a script that appends their configuration (eg. adding a vhost) automatically then roll it out across multiple servers. And then, for people who aren't doing a specific change and need to be able to see what's going on (eg. first time setup, where you're going through a lot of the options as you go anyway) can have the GUI open, where the GUI is just a pretty front end for the text based config underneath. Cisco routers work this way, they've got the web based gui that you can set things up in, or you can work in the CLI and config everything that way. Why not just offer both and give the users the choice to use whatever they please? Both CLI and GUI have advantages.
In other news, some random computer journal writer said the existence of the right hand should not mean we cut off the left.
How about something not working because you picked two options that conflict with each other? A gui would not allow that.
Why not? There's nothing inherent about a GUI that prevents you from making mistakes. A poorly designed GUI could very well allow you to select conflicting options, and a good one could make it obvious and prevent it.
On the other hand, a program using a text based config could just fail silently, or it could print a useful error message that points you directly to the problem. I'm quite certain you can make configuration from great to shitty and everywhere in between in either a GUI or CLI environment.
Apple has some work on this area that is instructice to consider. Have a look at Applescript, which is an (admittedly crappy) simple language for scripting GUI applications in a standard manner. I do hate Applescript very much, and consider it one of the worst languages ever, but still, the basic mode is the important thing here: GUI applications expose their functionality in a standard fashion through a textual interface that supports programming.
Are you adequate?
What do you mean "we," white man? You don't think embedded software development provides jobs? Very little of it has anything to do with GUIs.
This article is really about why you should use a provisioning system for backend process management. Using a CLI or GUI to complete the configuration are both lame choices.
Why pay engineers to continually make redundant configuration changes to backend systems at all?
Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e."
--Kenneth Thompson
True.
GUIs tend to limit the available choices, and if they're well designed, offer all of the combinations of choices that work, then allow you to remember what the choices were-- unless greyed out for logic flaws.
CLI was spawned back in the day of 32K worth of memory necessicitating clever concepts (pipes, stdin/out, and script manipulations) in shells that would deal with the need for extreme brevity. The CLI of today, depending on the OS, can have great breadth of control and scripted beauty. I think this is why Microsoft openned up a bit with the PowerShell concept.
They're not necessarily the dividing line between 'junior' and 'senior' admins, but they do connote a different level of understanding of what goes on underneath the hood. GUIs change a lot, and options change from version to version of an app, which in the non-FOSS world, have to happen frequently as a business model. In the FOSS world, I use commands I learned 30years ago, and can still use those commands, obtuse as they are, for probably another 30yrs.
---- Teach Peace. It's Cheaper Than War.
In the larger and and more critical config files usually we'd validate and keep it under revision control. Unless it's writing out an ascii config file, it's hard to diff a gui or work with example configs. It would be a major pain to take a screen shot of every tab if it's as vebose/complex as you described (and even harder validating from a screen shot of an old config).
The gui can have niceties like drop downs for enumerated lists or auto-correct for formatting (such as phone numbers).
You give humans too much credit.
Obviously so do you since you didn't understand that I wasn't talking about humans comprehending humans. I was talking about computers comprehending humans. But you made your point.
They don't work.
Contrary to the popular belief, there indeed is no God.
That's what we call bad design. Bad design can and has severely screwed up GUI interfaces as well. You had to specifically choose NFS because you are no doubt aware that the vast overwhelming majority of text config files do not care about whitespace and would not have this problem. This is an instance of the exception that proves the rule. It actually weakens your case when this is put into perspective.
A CLI won't allow that either -- you'll get an error message when you run the program with a faulty config file.
More cherry-picking that doesn't represent the majority of command-line tools. You have an opinion and I get that. The need to validate it by cherry-picking only those examples that reinforce it is known as confirmation bias. It'd be a lot more intellectually honest to acknowledge that what you have is a mere preference, that others are not bothered by the things about which you raise objections. In fact, others downright like them and think you're perfectly entitled to agree or disagree with their tastes.
Apache is a versatile daemon that can do many different things. There are GUI tools both commercial and open source that can configure an Apache server. Webmin is a free open source tool that can do that among many other things. Apache-GUI is a commercial tool. There are others beyond those two examples. If you are editing the Apache config files with a text editor on the command line it's because you are choosing the method that suits you.
Incidentally a long config file doesn't bother me. Hitting page down a few times is a similar amount of work to me compared to closing the file I'm working on and loading the next one in the text editor. The search function of any decent text editor is how you jump to the section you want instantly. I'll add that most users don't need to tweak every possible option of a complex daemon. Many times, you can use a small config file containing just the options you need. The long-form config files provided by default tend to be configuration examples for reference, with the majority of the content being comments to document them.
And if you really want, you can normally use a GUI that ultimately produces the same text config file you could have also made on the command line with a text editor. Most common programs have at least one available; many have several from which to choose. You still retain all the advantages of a human-readable text file that can be easily backed up, can be easily edited if something happens to your GUI or it is unavailable (i.e. an SSH session that doesn't have X), can easily be copied to other systems when you need to replicate settings, etc.
If the GUI could accept that screenshot as input and automatically check all the boxes for you, so that the GUI now matches perfectly the contents of the screenshot, that might be useful. Otherwise you're back to doing it manually and you're back to doing it the way you prefer -- CLI or GUI.
Use whichever one floats your boat. Really. I won't try to stop you. I don't need to feel secure about myself by converting you to my way of doing things. That's why I don't need to pretend like my way is
It is a miracle that curiosity survives formal education. - Einstein
Yes, but you'll likely end up specifying the verbal commands in a spoken language that's actually a semi-strongly typed pure functional language inspired by Haskell. Oops silly me! I forgot how to define the commutation relation between my xml parser monad and my route updater monad.
http://yaxu.org/category/haskell/
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
Which makes singing GUI? I suppose one could guide a mouse with pitch.
Someone had to do it.
But any person not able to use a CLI effectively is not a "computer professional" let alone admin material. Especially System administration, but basically anything that can be automatized is the domain of the CLI. Those that cannot use the CLI lack essential skills in what is still the most powerful human-computer interface method. GUIs are specialised tools and have a limited scope. Within that scope they may do fine, but that is it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e." --Kenneth Thompson
"creet"? That's even worse!
Are you adequate?
Why do we have so much text in GUIs?
It's set 300 years in the future; what'd you expect?!
Besides, that's just natural language parsing and AI. What's really impressive are the psychic doors!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Speech is less precise than typing, just as a GUI is less precise than typing.
Granular control requires precise input.
"This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
A dividing line in human history is the invention of writing. That's what differentiates pre-history from history. After the invention of writing we have records of what happens, before that it's up to archaeologists to dig ancient garbage dumps to infer things.
Incredibly, there are people who want to run the inverse way in computing.
What next, will we have to climb trees to use computers?
If you are unable to think of examples in which a GUI is better suited to configuration than a CLI, then I think you have TTV syndrome.
The rest of us see pros/cons on both sides of the issue.
if 'program' has a '--update' option in it, it's because someone thought to make that an option.
more often, it's "open .zip file, copy .foo file to the directory you installed program in, putting it in a subdirectory with the name 'bazz'"
meanwhile, the program i'm typing this into has a Help menu in the standard place with a "Check for updates" menu item. one click on that and then i do the obvious things and then not only don't i have to type in the name of 'data_src.db', i don't even have to know it, or the names of the 4500 other files i'd have to know and type in to update a browser the CLI way.
and there's that "and then i do the obvious things" thing. that just plain doesn't happen with CLI. to do it in CLI, I first have to find the documentation, then search it for something kind of like what I want to do, then try to figure out if that's really what I want to do...
GUI rarely loses comparisons to CLI, except in trivial cases. Get used to that.
Get (or write) software for the GUI that does the same thing the CLI does. Choose group of workstations. Put checkmark in box to select all and then deselect the ones you don't want. Click "OK". Done
Now you don't have to worry about having the wrong (or missing) character in your cryptic string of text commands.
What's really impressive are the psychic doors!
Boy are you going to be amazed when you return from the 1970's
Required reading for internet skeptics
My dotcom boss used to say "DOS is dead" when I was using command line in Windows NT3.5. Hmmph.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
..because after all, 640k should be enough for everyone.
Now, if you'll excuse me, I have backups to corrupt.
Big yawn to your solipsism. Philosophy moved on a long time ago.
Required reading for internet skeptics
Most people understand that body language and intonation are critical parts of effective communication.
(Not to mention the problems of giving commands to someone who doesn't speak the same language as you.)
Can't post a screenshot here. But I can describe it.
Hold your hand up, palm facing away from you. Now fold down your first, third, and fourth fingers and lap your thumb over your folded index finger.
There. Can you see it?
What's depressing is that WD-40 doesn't exist in the future to fix that sound they always make.
You'd think Starfleet would be suing whatever contractor made those damn things.
There's no -1 for "I don't get it."
After reading yesterday's post on Creating the Software Art In Tron Legacy I started thinking about the limited way I was using the shell in my day to day work. I was thinking that there has to be a better way, some sort of middle ground between the shell and GUI. I don't want to give up the power that the shell provides, I don't even want to take my hands off the keyboard - I just want a richer more contextual display. My computer is capable of rendering very slick graphics but my shell makes no use of it. Does anyone know of any projects that are working towards a graphically enhanced shell?
Unexpect the expected!
So many comments for a non-story. Yes, most people use both depending on their task, to make the task the most bearable. Both have their plusses and minuses which have been discussed time and time over. If you are one of those people who think that you are leet if you use CLI, or the other kind of person who thinks CLI is for basement dwellers only, I sympathize with you.
Because if you have a decent shell and you know how to program, half of what you do involves writing little programs for tasks that the GUI designer either did not anticipate, or could not support without incorporating a programming language. Most people who know how to use CLIs use GUIs for the jobs the latter do well, but users who cannot program have no idea of what they are missing from not being able to use the CLI effectively.
The MS-DOS command line is excluded here, by the above caveat of a 'decent shell'. Trying to do anything useful in a DOS box makes one realize just how clever the creators of Unix were. Fortunately, there is Cygwin...
There will always be a place for the command line:
GUI's make easy tasks easier, but hard tasks impossible.
(I have half a dozen command shell windows open at any given time in Windows -- unixtools for windows (sed, awk, grep, etc.) are absolutely invaluable to stay sane.)
... I think the fine article was completely misguided. For example, WSH script could have read the spreadsheet that eas mentioned, parsed the data into URLs that call the web interface for the "GUI" only router, and completed the task in much the same way as the article suggested that the CLI be used to solve the problem.
In other words, it's not the actual GUI holding the GUI Corp back, but a failure of admins to adequately understand the tools at their disposal. Given that the author is familiar with UNIX, he knows how to do things the Unix way. It should be no surprise that he doesn't know how to do an enterprise level roll out using Windows style tools.
Experts argue that humans should cut off their arms, as they are much worse than legs when used for tasks such as walking and running.
Just ask anyone old enough to remember Hypercard.
Or, for that matter, NetBeans.
New kids on the block may find the SSIS snap-in for MS Visual Studio to be a good example.
The problem isn't GUI vs, CLI per se. The problem is click and drool interfaces that sacrifice flexibility for simplicity and end up ony approriate for simple tasks.
"I hate these filthy neutrals Kif! With enemies you know where they stand but with neutrals? Who knows! It sickens me."
dragging computing back to the 'dark ages of the C:\ prompt.'
Well there's your problem right there. Comparing all command lines to a command line system where choice.com was king, loops were crafted from GOTO statements, and return values meant nothing consistent. Even the C:\ prompt in Win7 these days is much better. cmd.exe is passable with For, and powershell is quite nice. But [ba/[t]c/k/z]sh is better than anything native on a windows system, not to mention the standard gnu utils.
What is Google but a command line interface? Your browser url bar? Your start menu search box with integrated desktop search? Then there's something called the Web.
It seems CLI and GUI has been hybridized after a brief fad of flashy GUI (now isolated to gimmicky tablets). If you actually IT at the momment, rather than post on a website blog about the IT industry you'll find yourself working more and more with web interfaces. No CLI, no native GUI. It's just how it's all going to be done. (please take away some of the CLI and crappy native interfaces I have to deal with PLEASE!).
Ultimately 80x50 inline text sucks for representing any information. Since re-flowable HTML and the hyperlink it's as obsolete as dinosaur DNA. Ultimately you can sit down to a very powerful web app or the occasional well designed GUI and start getting shit done. You don't have to read the man page or all but read the source code to use it, which I might add, man pages still don't have examples. GUI you don't learn, you just use it. Ironically, most CLI work is done from a GUI.
Have worked with CLI for years, I cut my teeth on it way back, it still helps me out but I don't delude myself that CLI is somehow magical or is in some way a superior interface it's not. It's often epic usablility and discoverabiltiy fail and completely ignores advancements in human interface over decades). I don't need that doublethink in order to cope. Admit it, it sucks. But we use it at times and we get awesome shit done.
Thats what matters.
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
Simply use the right tool for the job at hand; both GUIs and CLI have their place.
This article reeked of 'get off my lawn'.
My gripes are less about GUI vs Command Line but more on the designs for these tools. I have used excellent CLIs and terribly horrible CLIs and the same goes for GUIs. If they are done well for their particular purpose then no argument from me, I'll use them. My concern is the # of GUI and CLI interfaces that make me pull my hair out when I go to use them. So often designers and testers are seem to not be testing real world scenarios nor real world scales and some designers seem to not have a clue when a GUI or a CLI is more appropriate. CLIs that are interactive only, don't use return codes effectively, and don't provide easy to understand outputs (where it takes a natural language parser to understand the output for example.) GUIs can offer a whole different set of frustrations.
When you can get the best of both worlds? gnome-do. I just type meta+space "te" return and I'm in the terminal. meta+space "ch" return gets me into Chrome. For more obscure programs, the visual feedback is nice, but the intuitiveness of typing is also very nice.
. . .counting my punch cards and listening to Elvis on paper tape. Oh, the good old days.
If proponents of the CLI feel threatened by the GUI, they must be horrified by the FUI.
On another tack, I did a quick search and nobody seems to be calling the new interface the FUI - Finger User Interface. It seems so obvious that I can't believe I'm the first to do so.
Both scenarios in at "CLI Inc." were cases of editing config files, not using a CLI. The same sed command that was used to modify the config for the BIND server and the Cisco box could have been done better with a good GUI text editor that supports regular expression based find and replace. The Windows admin could have done exactly the same text editing (at least for DNS), or could have scripted the whole thing. I've scripted a web based GUI more than once in my career.
.Net classes. Both are vastly superior to a CLI. Most Windows administrative tasks already have a CLI these days. If they don't, or if you want to make a better one, simply whip up a PowerShell script to use as a CLI.
The sad fact is that most Windows admins are bad at automation. However, it isn't the platform's fault. Windows is so easy to administer that any half-witted moron with enough persistence can manage to hold a job. There are a lot that are good at it and Microsoft has a plethora of tools for those who see the value in them. What is important isn't a CLI, but a usable API on which to build. CLIs are the "lowest common denominator" of APIs. UNIX and Linux have had a hard time establishing a common API, so that's what they are left with. Microsoft has been through several generations of APIs, each better than the one before. In the mid 1990s, any Windows admin worth his paycheck was doing VB Script with COM. Today, they are using PowerShell with
While command lines are powerful, and ill admit that the little i know of Linux has taught me it versatile, far more then windows. some people just have a hard time remembering command lines; I am a visual person and remember pictures better then words, therefore, GUI's work best for me. There is nothing wrong with either, Linux has its advantage and M$ also has its advantages (i know, i disgust myself)
If you watch some TNG episodes where Geordi interacts with the computer, you'll see him getting frustrated with it not understanding what he wants.
Geordi: "Computer, in the Holmesian style, create a mystery to confound Data with an opponent who has the ability to defeat him."
Computer Voice: "Define parameters of the program."
Dr. Pulaski: "What does that mean?"
Geordi: "The computer wants to know how far to take the game."
Dr. Pulaski: "You mean it's giving you a chance to limit your risk."
Geordi: "No, the parameters will be whatever is necessary in order to accomplish the directive. Create an adversary capable of defeating Data."
Pity it was a Pulaski episode.
Simple GUI's for simple jobs, and CLI's for more detailed jobs.
That's what Apple does with its servers, and it does it fairly well (still a way to go, but it's going in the right direction).
Nevermind the limited menu systems and the unidentifiable icons, GUIs lack any means for users to use multiple programs beyond the clipboard (mouse cut'n'paste) also available on CLIs.
For example, I type
$ du -m | sort -n | tail -69
to get the 69 largest directoriess under the current working directory (often but not always /). And something only slightly more complex to search logs for the IPs who have attacked me most. I have lots of neat one-liners like this stored in my command history ~/.bash_history and will often use one as a template for a new task.
${SUBJECT}. GUIs that do things in the background using the CLI are really the best that I have used. You get the benefits/eye candy of the GUI, but can script anything you need. Examples are Veritas volume manager and their cluster manager (hagui). They even get bonus points for logging the GUI's command line calls in a log file so you can see what was done. You do it once in the gui and then script the other dozen/hundred actions. (Or, help maintain a change log of the system for recover/rebuild purposes.) EMC's Legato used to do it as well. (Up to early 7.x, not sure how the newer 7.5/7.6 is doing things.)
Who the fuck is Paul Venezia, and why should we care?
Perhaps I'm trolling, perhaps I'm not.
Despite the heading, the article is "Things that can be scripted make batched actions easier and faster than things that cannot be scripted". The rest of the article is just strawmanning. (That's totally a word now...)
His router-changes example doesn't even use the CLI interface on the router, it has the router upload the script to a TFTP server, the admin edits it (not using a CLI, I hope, but some kind of text editing software), and causes the router to fetch it back and execute the script. Hell, a router with a web GUI doesn't even need a TFTP server, you can upload and download the file using HTTP. Or edit the script live with a handy javascript syntax checker, if your router developer's so willing...
I'm going to take this opportunity to scoff at his "lesson in IT", imperilled as I might be.
*scoff*
Paul "TBBle" Hampson
Paul.Hampson@Pobox.Com
An anecdote is not even data, let alone proof. And a hypothetical anecdote is even less.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
There's an article about MS bashing being kicking puppies, and here you are kicking cats... what has the (hello,) world (\n) come to?
using a command-line interface. I'm a huge CLI guy, but GUIs have their place.
That's the other thing about the CLI vs GUI debate. It doesn't only ignore the fact that you can use both together, but that some applications are neither CLI nor GUI. Yes, they have GUI versions, but emacs and vim are fundamentally not GUI applications. They are, let's speak it, full screen text mode.
Full screen text mode is not a CLI. There are editors that run in a pure command line. The most famous is ed. When vi was invented, it was a big step up from ed, but it wasn't a full replacement because it required full screen text mode.
Full screen text mode is certainly not a class of GUI. It doesn't require graphics. It may borrow concepts from a GUI, like pointers, menus, even windows, but it isn't graphical because it doesn't require the operating system to have graphics capabilities.
Full screen text mode is what we were using before GUIs took off. For certain tasks, it can be as usable as a GUI. It does, however become redundant when you have a GUI, hence vim and emacs get upgraded to GUI applications. The CLI, then, is the survivor, and full screen text mode gets written out of history.
Actually, the doors are completely silent but because the ADA is still in place 300 years from now due to political stagnation, the specs required a separate sound system to be installed with each door notifying blind crewmembers (pre-Geordi-banana-clip) that the door had opened.
I think Starfleet should be suing the contractor for not putting in seatbelts. I mean, really, it's common sense. If your inertial dampeners aren't 100% effective, and let some of those tiny shudders through when you take a few shots from a Romulan ship, you'd think the captain would like to stay in his chair for more than 60 minutes or so.
John
Ideally GUIs and CLIs would offer the exact same functionality just with different user interfaces. It's just as easy to design an unintuitive CLI interface by leaving out functionality as it is a terrible GUI interface by hiding functionality. The difference as I see it is simply that of re-usability. If you need to perform a function once or twice a year, there's no reason to use the CLI and have to remember an arcane notation set to achieve your goal. If it's a daily function or needs to be scripted, then CLI is perfect.
When are the teological discusions going to end. This is old news, and still people fight it as if their life depended on it. Chill out.
As humans we can make sense out of the lack of order in the linux commands. While the windows GUI with it's limitations is much easier to use. The sad part of the story is that we don't really have a better alternative to either of them yet. The windows powershell, althought I have not user it myself may be a wakeup call to Linux, or maybe not. While people are willing to learn arcane nomenclature and adhoc syntax, there is not really much any CLI alternative can do.
The bigger question is while we invest time in petty MS vs LINUX discussions, we miss the third alternative. What will be the better way to do what we do. the repetitive tasks. As well as ease of use and learning? Does a Steve jobs need to come and spell it out with a product (like he did with the iphone) before we can begin to understand that there ARE other posibilities!!!
That should be where our energies should be invested towards.
This is not equivalent. find does a deep search, while globbing */*.jpg will yield all files ending in *.jpg in the first level subdirectories (and only those files and directories whose names don't begin with a dot, except when an obscure shell option is enabled).
My exception safety is -fno-exceptions.
But this voice interface CLI exists today already and is widespread in a military setting. The only difference is that the orders are not parsed by a computer.
cpghost at Cordula's Web.
... it doesn't need an "API" proper. HTML allows for forms to be prefilled via URL calls. Since the fine article stipulated that the router had a web frontend as its GUI interace, a WSH script can prefill and submit any form thatt is displayed merely by calling a URL.
And, even were that were not the case, so long as the GUI widgets are named, WSH scripts can manipulate them programatically. And, even if they aren't named, there is the possibility that automation is possible via other mechanisms such as manipulation of hot keys, tabs, etc. I wrote some scripts in WSH to do performance testing circa 2005 that did just this. It called a series of proprietary programs, to time how long it would take to log into a database, complete specific tasks tasks, and log out.
CLI is best for admin work, a few scripts and you've semi-automated most of the admin work. Compare that to the click here-and-here-and-here method. That's why it takes less staff to admin a Linux service than a Win er .. GUI one. Even on the desktop, BASH and a few scripts achieves more in a few seconds than minutes of clicking ...
"Armed with printouts of the spreadsheet, the .. admins sit down .. and painstakingly go through each record .. one by one, typing in each address manually for each record .. It takes several hours at least -- and unbeknownst to them, they've managed to fat-finger a few addresses and swap a digit here or there in the blear of a late Friday night"
"Meanwhile, an admin over at CLI Inc takes the two address columns from the spreadsheet, copies them to a clipboard, and pastes them into a file on a Linux box. It's the work of 10 seconds to parse that into a usable sed script" link
...then you are not a professional.
What sucks is not the GUI, but the failure of the computer industry to provide the three natural user interfaces to the full user base population as a standard in all applications and OS's. And we know the constraints are done strictly for profit, but it is also the lie of imposed false constraints.
From Abstraction Physics
"Primary computer user interfaces:
Nature likes three (3) in primaries, as color in light (additive - red, blue, green) and paint (subtractive - blue, yellow, red) from which we can create all other colors in the rainbow. This applies to abstraction physics as well, as applied through the tool of computer, for there are three primary user interfaces. The command line, the Graphical User interface (GUI) and the side door port to application and functionality access (known by many different names and application levels such as API, IPC, DCOM, dcop, D-BUS, Plumber, computer sockets, etc., but each having its limitation and typically not so end user friendly as the concept should be.) And like the primary colors, if you take one away or limit its use, you constrain the ability of the user in putting new automatons together or modifying existing ones. Causing false limitations in user ability........."
Uh, using a GUI doesn't preclude you from editing text.
Isn't that like saying "A CLI is a graphical UI, because the monitor needs to be on to use it" or "A CLI can be made into a GUI by using an on-screen keyboard"?
In my mind there's a real distinction between inventing and typing textual commands, versus choosing stuff from a menu or list of choices. Links (say) is in the latter category. Yes, it's displayed on a text terminal, but it's more like a GUI in that the user chooses from a pre-specified list of commands or actions, rather than composes one of their own.
Some things are not best done by choosing from a list of pre-specified functions.
The CLI is like talking. Intent is expressed as a series of written phrases which could have been orally communicated to the computer provided that speech recognition worked effectively.
The GUI is like painting: Intent is expressed via a series of pictures and gestures.
Both ways have their pros and cons. They are complementary to each other.
A good GUI can do things the CLI does not offer, and the CLI can do things that are difficult to express via a GUI.
Here is an idea: a GUI application that allows the user to select one or more CLI commands via the mouse, then select the appropriate parameters from a list presented via the GUI, and then optionally linking commands together by drag-n-drop. The GUI could present previews of commands where possible, and allow the user to do an interactive modification of commands.
Is there such a beast?
The best interface would probably be a GUI on top of a CLI interface. There are programs that implement this. EagleCad for example has a command line box in the GUI where you can type in any command. The GUI itself only injects commands into the CLI when you click on the various widgets. The user can drive the program from either input, and sometimes the CLI box gets the job done where the GUI grabs the wrong object.
No, you don't get it. The doors aren't merely automatic like we have now; they somehow know to open if you want to walk through them or stay closed if you want to lean against them instead.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
You can't track an IP address in Visual Basic with a CLI. Ha!
http://www.youtube.com/watch?v=hkDD03yeLnU
Now do the same thing with [some] regular expressions. What?!?! Windows search doesn't take [some] regular expressions? My command-line has since the 1990s. I win. Too bad I didn't think of that as my initial example :D
-Clio
Karma: Bad (mostly from not giving a fuck)
Blog: http://clintjcl.wordpress.com
This got +5 insightful?? I see nothing but opinions based on two fundamental misconceptions:
1) Editing C# in a GUI editor means you are "programming in a GUI"
2) CLI == vt100
Why do some people insist to discuss the question if a screwdriver or a hammer is the better tool? I browse this site in a GUI and I perform complex file operations using pipes with a CLI. There is no way how either can replace the other fully without the overall usefulness of the system going down.
This is just silly: there are thousands of tools and dialogs for doing stuff in a GUI and there are thousands of commands and features and options for doing stuff on the command line.
In addition, a system that allows to do most important things thought the CLI in addition to the GUI has several advantages: typical tasks can be written down, copy-pasted and automated easily while you still can achieve it in the more intuitive and easy to remember graphical way too.
From a Security device perspective I find that the CLI is more flexible and less "you can't get there from here" problems than the GUI.
The GUI is wonderful if the Ethernet jack is setup correctly. If not, then you are screwed.
The CLI can always be accessed via a Console port and it is usually more flexible than the GUI for the "aw crap I totally messed up the IP addresses and hosed the device configuration and now the bloody firewall will not connect to anything" situations.
When the device is working I still find the CLI easier to deal with remotely since I have an SSH client on my IPad and Android phone. I found the CLI via SSH a simpler and more reliable process than with the GUI. Also the GUI drain the batteries faster for some reason. I could tether my laptop to the Android phone but the GUI still eats up batteries on both the laptop and phone plus I burn through my phone's data limit faster, assuming the device's GUI is even working correctly.
I have seen device's GUI interface lock up solid due to a rampant process or DDOS attack while the CLI still works, albeit at a snail's pace.
Now I do like the GUI to guide me through setup procedures I rarely use. Multiple choice is always better than having to totally recall arcane CLI commands for rare situations but to eliminate the CLI option makes as little sense as eliminating the GUI option.
"The Matrix[gui] is everywhere. It is all around us. Even now, in this very room. You can see it when you look out your window or when you turn on your television. You can feel it when you go to work... when you go to church... when you pay your taxes. It is the world that has been pulled over your eyes to blind you from the truth[console]. That you are a slave, Neo. Like everyone else you were born into bondage. Into a prison that you cannot taste or see or touch. A prison for your mind."
gui was/is a marketing trick played on dummies; it was invented for those intellectually lazy people who are always scared of [new] things they don't understand. and if you don't understand something you shouldn't confuse/scare yourself by pretending to be an expert in it. when a "sysadmin" claims that gui is better than cli (ROFL), you can almost see his carrier path in becoming a "sysadmin"; an old staff member with, in best case scenario, help-desk level of knowledge, which happened to be around when the decision was made to use computerz in a way that needed a server around. they couldn't (didn't bother to) hire a real sysadmin to do the job so they promoted him to $some-mouthful-it-title. to be fair, these people _are_ experts in one thing and that's office politics...
"most of these people are not ready to be unplugged. And many of them are so inured, so hopelessly dependent on the system, that they will fight to protect it."
more to the subject, that command line used as an interface is different that scripting a task.
"I'm trying to free your mind, Neo. But I can only show you the door. You're the one that has to walk through it."
"You take the red pill, you stay in Wonderland":
switch to runlevel $console-mode
chsh to zsh
put this in your .zshrc (among other goodies you find out there):
function zle-line-init zle-keymap-select {
RPS1="${${KEYMAP/vicmd/-- CMD --}/(main|viins)/-- INSERT --}"
RPS2=$RPS1
zle reset-prompt
}
autoload -Uz compinit promptinit
compinit
zle -N zle-keymap-select
zle-line-init(){
zle history-incremental-search-backward
}
setopt APPEND_HISTORY
setopt SHARE_HISTORY
setopt INC_APPEND_HISTORY
zstyle ':completion:*' verbose yes
zstyle ':completion::complete:*' use-cache on
zstyle ':completion:*:match:*' original only
zstyle ':completion:*:*:kill:*' menu yes select
zstyle ':completion:*:kill:*' force-list always
zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}'
zstyle ':completion::complete:*' cache-path ~/.zsh/cache
zstyle ':completion:*:approximate:*' max-errors 1 numeric
zstyle ':completion:*' menu select=1 _complete _ignored _match _approximate
zle_highlight=(region:standout special:standout suffix:bold isearch:bold)
bindkey -M isearch "^I" vi-repeat-search
bindkey -M vicmd '^[[Z' reverse-menu-complete
bindkey -M vicmd "^I" history-incremental-search-backward
"and i show you how deep the rabbit-hole goes".
Is that why point and click cameras play a recording of the sound of a shutter opening and closing by default?
I don't care why you're posting AC
>If you would be really proficient in bash, you would know, for instance, that your for would choke on filenames containing spaces - while his cat | read construction handles it well.
Does it?
This works for files with spaces:
for X in *; do ls "$X"; done
But if you don't use quotes, it doesn't:
for X in *; do ls $X; done
The OP's example should work.
I'm not a lawyer, but I play one on the Internet. Blog
CLI vs GUI is a silly argument. They both clearly have their place. When it comes to dealing with multitudes of devices or computers, the point is it's a lot easier to write a script to do massive numbers of configuration updates instead of having a room full of Phoenician oarsmen clicking away via web-based GUIs. A home router? GUI is fine. An enterprise WiFi access point that a company will have 200 of? CLI is essential.
There is a place for the command line, and there is no doubt, a place for the GUI. The key is using them in the *right place*.
-- $G
Hotwire, an innovative shell
http://code.google.com/p/hotwire-shell/
Click here to install on Debian/friends
PowerShell clone on Linux (warning: uses Mono)
http://pash.sourceforge.net/
Ruby-based shell:
http://rush.heroku.com/
I'm not a lawyer, but I play one on the Internet. Blog
Neat. I'll be watching for that now!
Required reading for internet skeptics
Think of the blind photographers!
Maybe, but that still doesn't explain why Microsoft Office still uses a floppy disk icon to mean "save."
There's no -1 for "I don't get it."
User: delete the temp folder. Computer: are you sure? User: Yes Computer: are you really sure? User: Yes, I'm really sure Computer: are you really really sure? User: just delete the fucking folder already. computer: porn folder deleted. User: aarrrgghh!!!!
I expect you'd find it quite unusual if someone tried to get you to do something just by pointing and clicking.
You've never been married, have you?
"A government is a body of people usually -- notably -- ungoverned." -Shepherd Book