|Contents||Bulletin||Scripting in shell and Perl||Network troubleshooting||History||Humor|
|Old News||Less is More: A rich functionality behind Spartan interface of Orthodox File Managers||Recommended Links||OFMs||OFM Book||Orthodox Editors||Classic Unix Utilities|
|KISS principle||Computing minimalism||Pipes||Programmable Keyboards||Sysadmin Horror Stories||Humor||Etc|
GUI with it's ability to display different fonts and graphic, provides more capabilities, than restrictive character-based interface. Nevertheless the character interface is really important and considered classic from another point of view: it is more programmable and more powerful than any GUI can ever be. Also we need to distinguish GUI interface from mouse-based check-drag-drop type of interface that is often associated with this term. It is just one possible implementation of GUI interface.
While impressive for simple tasks like browsing and media consumption, mouse-based check-drag-drop interfaces are simply are not efficient for more complex and repetitive tasks. In such cases they involve lots of tedious repetitive clicking, dragging and dropping. They are almost optimal when you need to copy a single file, or selection of files from one directory to another, but as operation became more complex they quickly lose luster.
It the same time GUI interface has important advantage: it provides better "situational awareness". Many classes of terrible errors committed by system administrators are related to what is called "loss of situational awareness". The latter is the ability to identify, process, and comprehend the critical elements of information about what is happening. Sysadmins be alert to any clues which might indicate that you lost situational awareness and it is easier to lose it when working with command line interface then GUI. Performing operation in wrong directory and deletion of wring files are two classic examples here. .
But there is also another fundamental problem with any rich, visually attractive GUI interface. A primitive character based interface with fixed width fonts (often called "console interface") has interesting property, they are by definition minimalist interfaces. Artists know well the saying "form liberates". In the same way puritan character interface liberates a programmer from spending too much time and effort on unimportant things ("cosmetics") and thus provides the possibility to spend most of the time implementing a richer set of operations.
|Many classes of terrible errors committed by system administrators are related to what is called "loss of situational awareness". The latter is the ability to identify, process, and comprehend the critical elements of information about what is happening (context of the situation).|
Most CLIs allow you to chain together commands (in Unix via pipes). Chaining is powerful; it allows a systems administrator to extend functionality of commands, scripts and entire applications in ways never intended by their designers. There are whole categories of tasks that are child's play with proper tool chain in a CLI that would be tedious (if not impossible) in a GUI.
Still there is no question about the fact that CLI interface is weaker then GUI in providing situational awareness about the Unix filesystem. Constant typing of ls commands by sysadmin who work with command line is a testimony of this fact ;-). While it is possible to improve this situation (see below) it by-and-large remains the same since 70th of previous century, when filesystems were much smaller.
It's also true that each interface has specific advantages and disadvantages:
Command-line interfaces are better for more complex actions, which you want to repeat (and possibly automate) and when you need to operate with many objects. They are closer to the advantages of Unix style command line shell operations which utilize advantage of human capacity for expressing complex thoughts in the artificial subject oriented language.
GUIs are better for using direct manipulation, and for using the selected object to narrow down the range of possible actions. GUIs take more advantage of our ability to quickly perceive and interact with images.
At the same time, paying too much attention/time/effort to the "face makeup" is characteristic to Windows developers and often negatively influence the core functionality of the product. The same temptation exists for Web sites... Here is a little bit exaggerated, but still mostly valid propaganda quote from RatpoisonWiki
Why are people choosing to say goodbye to the rodent? Why are they settling on a command-line interface when the rest of the world has moved on to the greener pastures of graphical desktops, glittering windows, and animated Adobe(R) After Effects(R)? Are they insanely flying in the face of progress?
No, quite the opposite, these people have mastered the [[HCI?]]. They navigate the desktop with ease without having to resort to icons and pointers. The computer obeys their touch-typed instructions and provides clear feedback on a full-screen display.
Free yourself from all the confusion over click-to-raise or sloppy-window focus. Forget about desktop decor, senseless glitter, and animations. Enjoy the extra speed of those CPU cycles that were wasted on the [[GUI?]]. Say goodbye (and good riddance) to the rodent and welcome the ultimate interface to your computer...
Here is what Wikipedia suggests (Command line interface - Wikipedia)
Advantages of a command line interface
Even though new users seem to learn GUIs more quickly to perform common operations, carefully developed CLIs have several advantages:
- All options and operations are invoked in consistent form, while with GUIs similar operations often appear on different menus with different interfaces and different applications have different approaches.
- All options and operations are documented (or should be), meaning that it is no more difficult to perform a rare operation than a common one.
- CLIs double as scripting languages (see shell script) and can perform operations in a batch processing mode without user interaction. That means that once an operation is analyzed, it can be saved in a script and consistently performed without further effort. With GUIs, users must start over at the beginning every time, as GUI scripting is more limited (and often nonexistent). Simple commands do not even need a script, as the completed command can usually be assigned a name and executed simply by typing that name into the CLI.
In other words limiting yourself to classic GUI interface is not wise. Command line interface , especially in mixed form when elements of the GUI can be used to help to form a command and provide feedback is powerful and available tools that should not be abandoned just because it is out of fashion. But the opposite danger also exists. In a way extremes meet: It is equally unwise to completely ignore GUI interface (and mouse as a very useful, excellent tool) like some Unix sysadmin prefer. There are situations when using GUI is much more productive.
And GUI interface itself should never be associated only with classic Windows-style interface. Other forms including hybrid are also possible. In this sense dominance of windows and Microsoft Office shut out all alternatives.
But, nevertheless, they do exist.
It's actually possible to have both keyboard interface capabilities and mouse-based drag and drop capabilities, kind of hybrid interface that has best properties of both. You can consider the ability to compose complex commands with the help of GUI on the command line to be a different type of GUI interface, then traditional "grad and drop" Windows style GUI interface. Ability to generate complex command line command with the help of GUI interface can be viewed as a special type of drag and drop, the form of drag and drop that is more powerful and flexible then traditional implementation of drag and drop.
In this sense Orthodox file managers such as Total Commander, WinSCP, etc and editors such as VI, XEDIT (and itts clone s such as KEDIT and THE) can be viewed as an attempt to provide a new form of GUI interface that is different from "pure" GUI "click-drag-drop" interface. In this case the concept of command line is used in an innovative way: as a space on which compilation of complex command is performed. In the simplest form implemented in OFM shortcuts such as Ctrl-F, Ctrl-[, Ctrl-], etc and macros such as Midnight Commander set:
provide the capability to insert elements displayed on GUI interface into command line forming (possibly complex) command(s) that also can contain user input, can be edited by the user, and eventually executed.
Advantages of such an approach are:
F5; F10; down; Enter
A long time OFM user replicate such keystroke sequences subconsciously using "autopilot". They
usually learn many such "precooked" keystroke sequences, sequences that solve frequent tasks and
use them like a piano player uses "accords". That's why the speed of some file operations
of an advanced OFM users look fantastic for uninformed observer.
Please note that OFM usage of the command line interface is different from the typical shell interface and can be called Visual shell interface.
OFM (especially in GUI-based incarnation) actually represent a hybrid model that combine advantages of GUI interface with the advantages of the command line: commands entered from the keyboard changes the panels and provide instant visual clues that are a trademark of pure GUI interface. This hybrid model has unique capabilities and somewhat resembles comics. You may try Scott McCloud's book Understanding Comics and Reinventing Comics for more information, as this sequel touches some interesting topics. Personally, I find comics, when done well, to be of the few examples when a picture is really worth a thousand words, and a couple of words are worth a thousand of pictures. IMHO this is also the case with OFMs ;-).
The other unique form of GUI interface is implemented in OFM user menu when elements from both panels can be used as parameters to pretty complex scripts. Scripts in user menu which is similar to favorites in Web browsers with small scripts instead of sites, permits macro variables that reflect the current status of both panels (path to active/passive panel, the current file on active/passive panel, selected files , if any, etc). This simple, ingenious, and very functional extensibility with custom shell scripts make OFM very attractive for system administrators. Here is an example taken from Midnight Commander User menu (which has a unique feature that it is dynamic and only those items of the menu that are applicable to the current file type and presence/absence of selected files are shown to the user):
= t r + ! t t y Gzip or gunzip current file unset DECOMP case %f in *.gz) DECOMP=-d;; *.[zZ]) DECOMP=-d;; esac gzip $DECOMP -v %f + t t Y Gzip or gunzip tagged files for i in %t do unset DECOMP case "$i" in *.gz) DECOMP=-d;; *.[zZ]) DECOMP=-d;; esac gzip $DECOMP -v "$i" done + f \.tar.gz$ | f \.tgz$ | f \.tpz$ | f \.tar.Z$ | f \.tar.z$ | f \.tar.bz2$ | f \.tar.F$ & t r & ! t t z Extract compressed tar file to subdirectory unset D set gzip -cd case %f in *.tar.gz) D="`basename %f .tar.gz`";; *.tgz) D="`basename %f .tgz`";; *.tpz) D="`basename %f .tpz`";; *.tar.Z) D="`basename %f .tar.Z`";; *.tar.z) D="`basename %f .tar.z`";; *.tar.bz2) D="`basename %f .tar.bz2`"; set bunzip2 -c ;; *.tar.F) D="`basename %f .tar.F`"; set freeze -dc; esac mkdir "$D"; cd "$D" && ("$1" "$2" ../%f | tar xvf -) + t t Z Extract compressed tar files to subdirectories for i in %t do set gzip -dc unset D case "$i" in *.tar.gz) D="`basename $i .tar.gz`";; *.tgz) D="`basename $i .tgz`";; *.tpz) D="`basename $i .tpz`";; *.tar.Z) D="`basename $i .tar.Z`";; *.tar.z) D="`basename $i .tar.z`";; *.tar.F) D="`basename $i .tar.F`"; set freeze -dc;; *.tar.bz2) D="`basename $i .tar.bz2`"; set bunzip2 -c;; esac mkdir "$D"; (cd "$D" && "$1" "$2" "../$i" | tar xvf -) done
- Dr Nikolai Bezroukov
SlashdotRe:Text displays in today's environment? (Score:1)by sdhoigt (1095451) writes: on Monday January 26 2009, @09:42PM (#26616279)Re:Text displays in today's environment? (Score:2)
> Not on the desktop, but there are large number of computer users who work on headless computers, and frankly don't want anything more than a console open with ssh.
I run X and still prefer MC; I have for years.
I've tried switching to Konqueror/Krusader/Thunar/etc., but I always go back to MC.
With MC's app bindings, there's really nothing you can't do w/it. And it's just so much faster to navigate around and get shit done.
Good luck MC devs!by extrasolar (28341) writes: on Monday January 26 2009, @09:54PM (#26616385) Homepage JournalRe:Text displays in today's environment? (Score:2)
Yes I know, and so did my colleagues, that its possible with todays faster conection speed to run a gui over that connection, but why bother when you can already get so much done in a console window?
Well, here's the problem, as I see it. The command line is an expressive interface, but largely limited to character-cell based interfaces. I just think we need to get out of that mode of thought. If you can take the command line out of simple character cells, that would make it even *more* expressive.
For instance, I love using maxima, but it's sad that its limited to a character cell interface. You can run imaxima or wxmaxima, which gives you a full, typeset interface, the best of both worlds, but it's still strange that these are just considered "additions" to the core program, and not a part of the program itself.
It's just silly that we have this unwritten requirement that every program must be usable in a character cell interface, it's like we want everything to be backwards compatible with pre-X interfaces. Why? On modern computing systems, why? You act like it's extra effort to support a graphical interface (not necessarily a WIMP interface), when on modern systems it really isn't.by ciggieposeur (715798) writes: on Tuesday January 27 2009, @08:11AM (#26620435)Re:Text displays in today's environment? (Score:2)
Well, here's the problem, as I see it. The command line is an expressive interface, but largely limited to character-cell based interfaces. I just think we need to get out of that mode of thought. If you can take the command line out of simple character cells, that would make it even *more* expressive.
(Disclaimer: I wrote a console-based terminal emulator [sf.net] to bring BBS-era convenience to the Linux console. Works pretty well, and can be very convenient at times.)
I think the issue is that the character-cell metaphor is a "good enough" interface for mouse-less work, especially with ncurses encapsulating 30 years of text terminals development. You can still add mouse and go (T)IMP too: see the OSS port of Turbo Vision [sf.net]. This metaphor also works over the simplest available two-way links ala ssh/telnet/serial port/etc. Once you break out of the character-cell metaphor, you've got the full X11 GUI that works over network too. The question is why would you seek any kind of intermediate ground when both metaphors already work OK?
My personal opinion is that the next great interface revolution won't occur until either a) voice commands become the norm, or b) we can project a HUD-like screen over our real sight (total immersion / augmented reality). I suspect B will happen first, and it will probably come in a form like the Nintendo WII where multiple 3D pointers are used.by Sir_Kurt (92864) writes: on Monday January 26 2009, @05:33PM (#26613245)Re:Text displays in today's environment? (Score:2)
Text mode apps are great because they fire up quickly, look and act the same on different platforms, can be highly functional and flexible, and use moderate resources. For all these reasons, they will use less of your time. So if your time is important to you, learn to use them.
Kurtby idontgno (624372) writes: on Monday January 26 2009, @05:51PM (#26613545) JournalPoint well taken (Score:2)
Do text apps still have a place in today's world?
I tried to reply to you in pictographs and hieroglyphs, but accursed slashcode forces me to use text.
I would rather have these programmers focus their efforts on Krusader ? It seriously needs some love.
So jump right in! Meanwhile, no programmers are being drafted against their will to work on one program over another.
(This is a longstanding gripe of mine at the fringes of Free Software. "That developer shouldn't be wasting his time on <program x>; <program y> needs the attention more!" "Free Software" is not a monolithic corporate product with its own integrated master schedule with a list of prioritized deliverables. It's the aggregate of dozens of labors of love, and if Developer Joe decides he wants to spend time with mc rather than Krusader, who are you to say otherwise?)by bogaboga (793279) writes: on Monday January 26 2009, @06:09PM (#26613841)Re:Point well taken (Score:3, Interesting)
I understand what you are saying. Sadly, it is this very paradigm that will keep us from "world domination" yet we have the resources.
Sad indeed! 10 years from today, we'll still be where we are now...you might ask: Where? I would answer: STUCK in the corridors of irrelevance when it comes to the desktop.by Hatta (162192) writes: on Monday January 26 2009, @06:20PM (#26614011) JournalRe:Point well taken (Score:2)
I'm pretty sure the people working on this project would consider anything "desktop" oriented irrelevant.
If I can type 'mc', hit a bunch of hotkeys, and be done in a couple of seconds isnt' that a tool worth having? I can do a hell of a lot with mc before krusader even loads up. And I don't even have to take my fingers off the keyboard.
That's not irrelevant to the desktop, that's a superior alternative to the desktop.by jedidiah (1196) writes: on Tuesday January 27 2009, @11:49AM (#26623119) HomepageRe:Text displays in today's environment? (Score:2)
The big problem with this sort of "holier-than-thou" attitude is that it
can be applied to more than just something like MC. You can use this as
an excuse to belittle ANY project that doesn't fit into your rather
limited view of what should or shouldn't be on the desktop.
This mentality doesn't just apply to console tools but it also applies
to alternative desktop tools as well as highly specialized GUI apps.
It can apply to anything that doesn't suit the desktop nazi du jour.
If I wanted that kind of crap I could have just stayed with Windows.
Mebbe I don't want to use the what the rest of the herd uses.
This applies equally well to vi or KDE.by dbcad7 (771464) writes: on Monday January 26 2009, @07:43PM (#26615137)Re:Text displays in today's environment? (Score:1)
If you made a mistake in editing say your xorg.conf file, and upon reboot X will not restart.. mc is THE easiest editor to use.. bar none.. and it is easy to use for copying, renaming, moving files etc.. especially for those who don't often use the command line. It was standard to include it in all distros by default, and that was a good thing,. sadly not so much now
.. If whatever distro I get doesn't have it, I always make sure I download it so it's there for emergencies.by bruunb (709544) writes: <bbj@@@swooplinux...org> on Monday January 26 2009, @11:43PM (#26617387) Homepage JournalRe:Text displays in today's environment? (Score:2)
Don't take this the wrong way, but I laughed out loud when I read you comment, I feel the same way about the MC editor (and any other for that matter
:w appears often when I'm in a GUI program). CLI + VI(M) and you have all you need. Gnome/KDE is only for having mulitple terminals open on one screen - great for log-watching when developing.by CronoCloud (590650) writes: <cronocloud.mchsi@com> on Tuesday January 27 2009, @12:06AM (#26617597)Re:Text displays in today's environment? (Score:1)
I feel the same way about the MC editor (and any other for that matter
:w appears often when I'm in a GUI program).
You can probably guess what happened when I used mc's editor. I moved the cursor where I wanted to edit and hit "i". And there it appeared, an "i", taunting me. Worse was some time back when I was using Notepad on Vista. I had finished editing and wanted to save and quit, and absentmindedly hit Esc and then did "ZZ", and wondered why it didn't save and quit and then noticed that "ZZ" sitting there. And I constantly try to middle click paste on Windows it's always tripping me up. Happens at least once, every time I use Windows.
I'm not a developer or admin so don't need to juggle a large number of terminal windows (and I don't use GNU screen) but I do use the mrxvt tabbed terminal.by bruunb (709544) writes: <bbj@@@swooplinux...org> on Tuesday January 27 2009, @12:18AM (#26617685) Homepage JournalRe:Text displays in today's environment? (Score:2)
I never got that ZZ or
:wq thing that I see a lot of coworkes use? I always use :w when I've made or finished a sentence and :x to quit and save. Rarely the :q! option. I think it comes from the old unstable network days at the dorm in the late '90... I must be getting old or something like that:xby graibeard (220988) writes: on Tuesday January 27 2009, @01:08AM (#26618029) HomepageRe:Text displays in today's environment? (Score:2)
[Esc] 9 -> Options -> Configuration ->  use internal menu (under 'Other options')
Do that and it will probably default to vi (vim) ie:- the system default editorby mattack2 (1165421) writes: on Monday January 26 2009, @10:11PM (#26616537)Re:Text displays in today's environment? (Score:2)
I realize it's mostly for file management, but I've seen others mention that it has a file editor.
So is it easier than pico? Personally, I can't *stand* pico (and wouldn't use pine/alpine if I couldn't turn off pico and a bunch of other beginning-user-friendly things in it).. but it is pretty dang easy to use.by dbcad7 (771464) writes: on Monday January 26 2009, @10:42PM (#26616819)Re:Text displays in today's environment? (Score:2)
The editor in mc, is much like the dos editor from windows.. yeah it's pretty easy. Probably not a good programming editor, but very good for quick edits of config files.by Ash-Fox (726320) writes: on Tuesday January 27 2009, @06:14AM (#26619717) HomepageRe:Text displays in today's environment? (Score:0)
It has syntax highlighting and a few other nifty features while being brain-dead simple.Re:Text displays in today's environment? (Score:0)
by Anonymous Coward writes: on Monday January 26 2009, @05:27PM (#26613111)
Do text apps still have a place in today's world? That's like asking if we still need screw drivers when there is "The Flexible Shaft Ratcheting Screwdriver" (as sold on ThinkGeek, just below the comment I am commenting on when I was reading Slashdot).Re:Text displays in today's environment? (Score:0, Offtopic)
by feldicus (1367687) writes: on Monday January 26 2009, @05:57PM (#26613623)
Hey, in the "Flexible Shaft Ratcheting Screwdriver's" defense, you can use it to drive a threaded, helical shaft via torque applied to a slotted protrusion after you're done using it to make steak fries, or whatever else the kids are eating these days.
feldicusRe:Text displays in today's environment? (Score:2)
by julian67 (1022593) writes: on Monday January 26 2009, @05:35PM (#26613267)
There's very much a place for console applications. If you ssh into a machine that has no graphics capability you'll have an awful lot of trouble running Krusader on it
;-) There are lots of great applications which use curses/ncurses to offer interfaces and facilities analogous to gui apps and there are also plenty of apparently low end machines out there on which running X and a desktop is too expensive, i.e. start x and watch everything else hang, but when run without X the same machines are perfectly suited to their tasks and have years of useful life ahead of them. I also have an amd64 PC with 2 GB RAM, nvidia GPU etc. MC is installed and gets used regularly on that as well. That says a lot for the capabilities of MC but also some not so favourable things about GTK file managers.... Anyway I'm pleased to see there are people interested in reviving development of MC.Re:Text displays in today's environment? (Score:2)
by WuphonsReach (684551) writes: on Monday January 26 2009, @11:36PM (#26617321)
Do text apps still have a place in today's world? Heck, network speeds and capacities (read bandwidth) have improved a great deal. I would rather have these programmers focus their efforts on Krusader ? It seriously needs some love.
It's a lot easier to log what I do at the command line then what I do in a GUI. Which comes in handy 6-18 months down the road when I'm trying to remember what the heck I did to configure XYZ. And a 132x50 display area for a console is nice and roomy.
In fact, lack of logging is one of the things I dislike about Windows now. I would have to take copious screenshots in order to keep track.
(We also use FSVS with a SVN storage repository to keep track of changes. The log files are more for my convenience.)Re:Text displays in today's environment? (Score:2, Interesting)
by Risen888 (306092) writes: on Tuesday January 27 2009, @02:31AM (#26618533)
Have you used the svn version of Krusader lately? I think it's better than ever. What "needs love?"
But more importantly, a whole hell of a lot of what I love in Krusader came straight out of mc. I couldn't be more thrilled with this news.Re:Text displays in today's environment? (Score:2)
by zombie_monkey (1036404) writes: on Tuesday January 27 2009, @05:41AM (#26619579)
I prefer CLI and ncurses apps, because they are designed for a keyboard interface. I have found console-based apps for all my needs, and the only thing I run most of the time I run a screen session in urxvt and forefox with vimperator, which also saves me form having to reach for a touchpad/mouse. This is of course doable also with ratpoison, xmonad, and others, but in GUI apps ease of control exclusively form the keyboard is not usually a big priority.Re:Text displays in today's environment? (Score:2)
by value_added (719364) writes: on Tuesday January 27 2009, @11:12AM (#26622469)
Do text apps still have a place in today's world? Heck, network speeds and capacities (read bandwidth) have improved a great deal.
You're probably seeing things from the point of A User and His Desktop, so I'll skip the installation, updates, maintenance, monitoring etc. tasks that are workaday experience for any sysadmin, or anyone working with more than one or two machines, and describe my own experiences from a similar point of view.
I recently upgraded my home network to gigabit. The reasons for doing so were multiple, and I regret having waited so long do so. That said, my daily email, usenet, torrent, etc. activities are all done using text-based interfaces. My file management (naming, organising, sorting, archiving, burning of CDs and DVDs, etc.) is done using a text-based interface, as is routine maintenance (networking, backups, etc.), the usual writing and printing letters and documents. And finally, because my primary workstation isn't Windows, my "desktop" configuration is done using a text-based interface.
Mind you, I do use a GUI browser for most websites, but your question could be rephrased as "Why are you opening all these windowed applications to perform tasks that could better be done using a simpler and typically more feature-filled approach that's already at your fingertips?"
Text is the closest and most direct method of interfacing with your computer. That was true decades ago, and it's just as true today. If using a text-based approach requires too much thinking or learning, then by all means, click on that icon. By the time the program loads and you rummage around in menus to find what you want to do, I'll have already done it and moved on to something more interesting. Like reading the latest Slashdot story about Midnight Commander.
by MacTO (1161105) writes: on Tuesday January 27 2009, @11:00PM (#26633345)
Ever try to share a 2 Mb/s connection with a town of 1200 people? Point is, not everyone in the world can have high speed because not everyone in the world has access to high speed. Even if you do have high speed, you may not be able to install an X server or VNC client on someone else's machine while travelling -- but chances are that you can still run PuTTY. I've heard of people running ssh clients on mobile devices, where bandwidth may be a wee bit expensive.
And then there are the people who run mc because they just happen to prefer it.
Re:Text displays in today's environment? (Score:0)by Anonymous Coward writes: on Thursday January 29 2009, @11:15PM (#26662099)
I would rather have these programmers focus their efforts on Krusader ?
Check the respective git/svn repositories. As of last week there were 2 people actively working on MC. Plus two more on http://mc.redhat-club.org/ [redhat-club.org] fork, currently being integrated in the mainline (Unicode bugfixes mostly).
Krusader already has 4 active developers.
...GUI supporters say the visual nature of the interface makes it easy to use, and helps users find features and work out which bits of an application depend on other parts: select an option over here and an option over there changes as well
As long as users understand the fundamentals of "how the computer works", then a GUI allows them to find whatever it is they need quickly and efficiently. They can rely on visual cues so they don't have to pay rapt attention to the screen at all times.
For my part, I have found GUIs useful. If an application has a graphical interface that follows any of the common design conventions, I am confident I can make it work; even if I've never seen it before in my life. I can make the transition from Windows NT directly to Windows Server 2012 over to Mac OS X and through to Gnome, Unity and even Webmin without having to relearn everything from scratch.
The downside to GUIs is that they rely on this steady consistency. Any change to a user interface has to be handled delicately, and it almost never is. This is part of the reason why I don't get along well with Microsoft's Metro interface for Windows 8
Where's the power?
The other side of the debate is the "real men use the command line" camp. They lead in with the hard-to-counter fact that command-line interfaces (CLI) are more powerful and flexible than GUIs. What you can do with Bash, Grep and regular expressions is light years ahead of anything offered via searches in a point-and-click interface, even today. As an added bonus, CLI-optimised systems tend to store configurations and settings in flat human-readable files. Flat config files are easier to backup, migrate, and create scripts to manipulate.
If you really know what you're doing, then a powerful CLI employing Bash can allow you to truly unlock the potential of your computer in a way that a GUI never will. A GUI is always limited to the preconceptions of its designers; the metaphors they use, the combinations of commands and scriptlets they felt should, would and could work together.
Most CLIs allow you to chain together commands (sadly Goosh still doesn't). Chaining is powerful; it allows a systems administrator to marry commands, scripts and entire applications in ways never intended by their designers. CLIs allow a systems administrator to push the boundaries of what is possible with the software available. There are whole categories of work that are child's play in a CLI that would be tedious (if not impossible) in a GUI.
The flip side of the coin is that CLIs require a great deal more rote learning and memorisation to use. You need to read a lot of documentation and manuals before it becomes more powerful than a GUI, and there are still plenty of things a GUI takes care of for you that would be monotonous in a CLI.
Lack of standardisation is another issue; we don't live in a utopia where every operating system uses the same CLI. I, for one, have zero interest in learning a new CLI for every OS. It will take me quite some time to become as familiar with the intricacies of PowerShell for Windows as I am with Bash and its fellow tools.
With the basic arguments of both sides laid out, the root of my confusion with this debate is how very polarising it is. Forum denizens the internet over seem to view CLI versus GUI as a binary choice; you either use one or you use the other. I simply cannot grasp this; why limit yourself either way?
Avoiding CLIs entirely borders on career suicide. By the same token, if a GUI makes a certain administration task easier, why not make use of that tool? There is more than enough room for both forms of computer interaction within the practice of systems administration. ®
The traditional UNIX user interface is a simple command-line shell.Linux GUI vs. Command Line
A text-only terminal window with a fixed number of lines (usually 24) and columns (usually 80) is controlled by the shell program.
The shell prints a prompt when it is ready to receive commands. You use the keyboard to type in a command. Then the shell parses and processes the command and executes it for you. The command prints its output, if any, to the same terminal window. When the command is done, the shell prompts you again to enter another command.
In general, the terminal window has no graphics capability, although there are specialized graphics terminals and some UNIX programs know how to display (usually monochrome) images on them.
Modern personal computers have all moved away from command-line interfaces and created graphical user interfaces (GUI).
In a GUI, there are menus or pictoral displays showing all programs that you can run and files that you can access. A pointing device (usually a mouse) is used to select items from the menus or displays.
Individual programs open a "window" within the monitor to display their output, and can display either text or color graphics as needed.
The keyboard is primarily used to enter text or data, although there are often keyboard equivalents to the various menu options.
There is a GUI shell available for UNIX systems, called "X-Windows" or simply "X".
This GUI has all the same features that you would find on a personal computer. In fact, the version used most commonly on modern UNIX systems (CDE) is made to look very much like Microsoft Windows.
The X-Window system goes beyond personal computer GUIs in that the GUI and the programs that you run within the GUI can be executed on one or more networked computers, such as servers, but all the windows can be displayed on one networked computer or a simple X-terminal device.
UNIX programs that date from the traditional command-line days have to be rewritten to make use of the X-Window GUI system, so the standard X-window environment usually includes a simple terminal window running the traditional UNIX shell. That can be used to execute the many traditional commands that do not directly interface to the X-Window GUI.
In the Linux Forum, there is an interesting debate going on about GUI (Graphical User Interface) and CLI (Command Line Interface), two modes for users to interact with the computer. Valid but opposing arguments were made by both sides:
-- GUI makes it easy for the user, therefore makes the OS user-friendly.
-- GUI interface means the OS is "dumbed down"
-- CLI gives the user more control and options.
-- CLI is stone-aged; it belongs to a "The History of Computers" museum.
-- Xwindows is progress compared to the CLI.
-- Xwindows presents a really big security risk...load it and you are asking to be hacked.
-- Using GUI is faster. Picking and choosing icons sure beats trying to remember and typing command lines.
-- Using CLI is faster. A keyboard is pretty much all you need here, much faster than all that clicking, scrolling, clicking some more, scrolling some more, and more typing, then clicking.
-- GUI consumes too much CPU and memory.
-- With newer and more powerful computers, that is not a problem. And its benefits are well worth it.
My feeling is that people's strong preference for one interface and stern rejection to the other are sometimes more psychological than technical. There are those who are afraid that without the comfort of the colorful clipart they have grown accustomed to seeing on their screen, the blank screen will take them right back to the dark ages, when computers were handled only by a few tech wiz'. At the other end of spectrum, there are those with what's known as the "superiority complex" over GUI. For these people, GUI is totally beneath their über-geek status and mastering CLI is matter of wiz-kids honor.
The truth, as usual, lies somewhere in the middle. CLI and GUI are essentially complementary modes of interacting with the computer. CLI is generally easier if you can remember the commands and the options, which is the case if you use them a lot. If you don't use certain functions a lot, a nice GUI can help you find them quickly. Of course whenever you have to repeat a command many times you should automate the process by writing a script, but in theory you could link that script to a button or menu item in a GUI. It doesn't have to stay at the command line.
So, in the user-friendly vs. control and options debates, both sites have a point. But there is a third point: GUI and CLI can be used together to achieve great things that either one alone can't. This is particularly true with Linux where the user is given the flexibility of switching back and forth between GUI and Command Line easily. One example is that Linux CLI and GUI can give the user the ability to work on any computer on the network as if you were sitting at that computer. On Unix/Linux (running X-Windows) all you need to do is use the xhost command to specify which computers you want to allow access, and the DISPLAY environment variable to specify on which computer you want to start the GUI of the program you want to run.
On the subject of keyboardability, posted 11 Feb 2001 by RyanMuldoon
The mention of XMLTerm reminded me about the EFM approach to integrating the command line with the GUI. EFM had a graphical file listing, but you could also just start typing in commands. It worked pretty well. My understanding is that Nautilus may incorporate this feature post-1.0. That would probably be rather useful. It doesn't solve the issue of having commandline tools pop up GUI windows and such, but it does manage to avoid it. Nautilus is setting out to create GUI tools to eliminate the need for CLI. As much as I'd like to think otherwise, I still can't use linux without a console. I don't even notice it - but a novice user most definitely would. What we should try and focus on is incorporating (or even surpassing) the expressiveness of the command line into the simpler interface of the GUI. Pointing, clicking and dragging has basically no semantic value right now. I have high hopes for what things like "emblems" in Nautilus could do - little symbols that you can attach to an icon that represent an action. If you think about it, that has a lot of power if it is implemented well. That should be complemented by the ability to use things like Nautilus or EFM like "graphical shells" - not filemanagers per se, but just a graphical context for inputting commands. Of course, as I said in my last post, such things would benefit even more by a semantically richer filesystem and increased metadata. But that requires a pretty big change.
Sort of., posted 11 Feb 2001 by egnor
Some aspects of the command line need to remain on the console, so they can be piped to other programs. And even if everyone has a GUI, system processes often have no interface at all. If 'tar' always pops up a status bar, what happens when 'tar' is running from a cron job? Does the logged-in user get a random status bar on their screen?
You are also presumably assuming some sort of remote-display system that's at least as efficient as a remote console. (X is no good; I can use command-line tools over a 300bps link if that's what I have, but the X protocol doesn't work well until at least 64k-128k or so, and in many cases not even then.)
If you solve these problems, what you're left with is the Plan 9 user interface, give or take. Plan 9 takes the philosophy that consoles are dumb teletypes (no VT100 emulation); if you want output that can be redirected, use the console; if you want something like 'curses', that's what the GUI is for. (And yes, transparent remote access to everything is possible.) It's not a bad model; the VT100 character-grid interface really has no reason to exist.
(If you don't solve these problems, but merely brush them under the rug, what you're left with is the Windows user interface, give or take.)
Is that what you had in mind?
Some programs, posted 11 Feb 2001 by nether
This is not an entirely new idea. For example, there's Ion, a window manager that's designed to be used with a keyboard. (Yes, you can use it with a mouse, too, but it's not quite what you're used to.) I use it all the time.
Ion doesn't provide much in the way of integrating command-line tools with a GUI (try XMLterm for that), but it's definitely a step towards closing the gap between "console" and "GUI".
Some of this already works in KDE 2, posted 11 Feb 2001 by tackat
> What if the Unix GUI didn't need a mouse? What if every application could be controlled solely with the keyboard?
This is already possible in KDE 2 for a long time via DCOP. Fire up kwrite (make sure you don't have two kwrites there at the same time -- otherwise you have to add the pid to those commands) and type into your favourite xterm:
dcop kwrite KWriteIface insertText 'Windows rocks!' true
dcop kwrite KWriteIface setCursorPosition 0 8 true
dcop kwrite KWriteIface insertText 'sux! KDE ' true
dcop kwrite KWriteIface shiftHome
dcop kwrite KWriteIface writeFile 'conquer_your_desktop.txt'
or check your Mail using KMail by entering:
dcop kmail KMailIface checkMail
or bind the command "dcop kdesktop KScreensaverIface lock" to your "Pause"-key using kmenuedit. That way you can start kscreensaver by pressing the "Pause"-key.
To explore the possibilities you might want to use kdcop.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes. If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.
ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2015 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down currently there are two functional mirrors: softpanorama.info (the fastest) and softpanorama.net.|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: December, 05, 2014