Softpanorama Bulletin
Vol 24, No.05 (May, 2012)

Prev | Contents | Next

GUI vs Command line interface

GUI with it's ability to display different fonts, provides much more capabilities, than restrictive character-based interface. Nevertheless the character interface is really important and considered classic from another point of view. Also we need to distinguish GUI interface from mouse check-drag-drop type of interface that is often associated with them

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 file from one directory to another, but as operation became more complex they lose luster.

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 and thus provides the possibility to spend most of the time implementing a richer set of operations.

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 toolchain in a CLI that would be tedious (if not impossible) in a GUI.

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...

It's actually nice to have both keyboard interface capabilities and mouse-based drag and drop capabilities. you can consider composition on complex commands on command line as a special case of drag and drop, the form of drag and drop that is missing in typical GUI-based interfaces.

It's 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.

In this sense Orthodox file managers and editors such as VI, XEDIT and THE provide a new form of GUI interface that is different from "pure" GUI "click-drag-drop" interface and manages to use the concept of command line in an innovative way. In it special macros insert elements from GUI into command line forming (possibly complex) command that also can contain user input and that eventually is executed. Advantages of such an approach are:

• The more complex the file operation is, the less suitable it is for "drag-and-drop. For complex file operations often it is necessary to generate a command line using hotkeys that insert into it a particular parts of the panel image.
  
• A custom extensions of OFM via shell scripts in user menu and extension menu are step forward in comparison with pure Unix command line interface. Having half screen panels with files above provide better visibility of the environment and cur the number of mistakes and/or blunders that are very costly in command line. One letter hotkeys are very convenient for quick invocation of often used scripts (they can operate on elements of the current context like the current file, current directory or the list of selected files. This approach allows quick, errorless and semi-automatic performance of routine tasks such as copying or moving files from one directory to another, compression of archives, decompression, installation of packages (like in piano playing). Generally mouse is more convenient for less frequently used operations where you cannot acquire "piano-style" automatism based on frequent repetition of the same operation.
  
• Even simple one file operations are mostly faster with the keyboard than using drag and drop and the time difference increases with the complexity of operation, level of experience and the level of familiarity with the particular task and OFM. For example, to move the current file to the (only) subdirectory in the current directory one needs just four keystrokes:

  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.
  

• Keyboard proves to be the lowest common denominator of all interfaces, although now with high quality GUI environments this is less the case that the past. Still in some situation it remains the only available interface (troubleshooting sessions when X server is broken or is not installed for security reasons, bad connectivity/slow lines, hand-held devices, etc.). Remote troubleshooting is especially important consideration. This means you will always have a very convenient working environment in situations when you need it most. And you can use all your skills polished for years when you really need to do the work fast. That's not the case if you normal environment is GUI-based and you need quickly to adapt to the plain-vanilla command line.

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

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.

NEWS CONTENTS

• 20120910 : Sysadmins! There's no shame in using a mouse to delete files • ( The Register )
• 20120910 : Command-line shell versus Graphical User ( Command-line shell versus Graphical User , )
• 20010212 : Are Unix GUIs all wrong ( Are Unix GUIs all wrong, Feb 12, 2001 )
• 190821 : Midnight Commander Development Revived - Slashdot ( Midnight Commander Development Revived - Slashdot, )

Old News ;-)

[Sep 10, 2012] Sysadmins! There's no shame in using a mouse to delete files •

The Register

...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. ®

Command-line shell versus Graphical User

The traditional UNIX user interface is a simple command-line shell.

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.

[Feb 12, 2001] Are Unix GUIs all wrong

What if the Unix GUI didn't need a mouse? What if every application could be controlled solely with the keyboard? What if every new window that you popped up got the focus by default (this works with click-to-focus, but you need window manager help with focus-follows-mouse). See also Slashdot discussion: Are Unix GUIs All Wrong

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:

--snip--

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'

--snip--

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.

Midnight Commander Development Revived - Slashdot

Re:Text displays in today's environment? (Score:1)

by sdhoigt (1095451) writes: on Monday January 26 2009, @09:42PM (#26616279)

> 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!

Re:Text displays in today's environment? (Score:2)

by extrasolar (28341) writes: on Monday January 26 2009, @09:54PM (#26616385) Homepage Journal

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.

Re:Text displays in today's environment? (Score:2)

by ciggieposeur (715798) writes: on Tuesday January 27 2009, @08:11AM (#26620435)

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.

Re:Text displays in today's environment? (Score:2)

by Sir_Kurt (92864) writes: on Monday January 26 2009, @05:33PM (#26613245)

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.

Kurt

Re:Text displays in today's environment? (Score:2)

by idontgno (624372) writes: on Monday January 26 2009, @05:51PM (#26613545) Journal

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?)

Point well taken (Score:2)

by bogaboga (793279) writes: on Monday January 26 2009, @06:09PM (#26613841)

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.

Re:Point well taken (Score:3, Interesting)

by Hatta (162192) writes: on Monday January 26 2009, @06:20PM (#26614011) Journal

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.

Re:Point well taken (Score:2)

by jedidiah (1196) writes: on Tuesday January 27 2009, @11:49AM (#26623119) Homepage

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.

Re:Text displays in today's environment? (Score:2)

by dbcad7 (771464) writes: on Monday January 26 2009, @07:43PM (#26615137)

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.

Re:Text displays in today's environment? (Score:1)

by bruunb (709544) writes: <bbj@@@swooplinux...org> on Monday January 26 2009, @11:43PM (#26617387) Homepage Journal

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.

Re:Text displays in today's environment? (Score:2)

by CronoCloud (590650) writes: <cronocloud.mchsi@com> on Tuesday January 27 2009, @12:06AM (#26617597)

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.

Re:Text displays in today's environment? (Score:1)

by bruunb (709544) writes: <bbj@@@swooplinux...org> on Tuesday January 27 2009, @12:18AM (#26617685) Homepage Journal

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:x

Re:Text displays in today's environment? (Score:2)

by graibeard (220988) writes: on Tuesday January 27 2009, @01:08AM (#26618029) Homepage

[Esc] 9 -> Options -> Configuration -> [] use internal menu (under 'Other options')
Do that and it will probably default to vi (vim) ie:- the system default editor

Re:Text displays in today's environment? (Score:2)

by mattack2 (1165421) writes: on Monday January 26 2009, @10:11PM (#26616537)

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.

Re:Text displays in today's environment? (Score:2)

by dbcad7 (771464) writes: on Monday January 26 2009, @10:42PM (#26616819)

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.

Re:Text displays in today's environment? (Score:2)

by Ash-Fox (726320) writes: on Tuesday January 27 2009, @06:14AM (#26619717) Homepage

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)

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.

feldicus

Re:Text displays in today's environment? (Score:0, Offtopic)

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)

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, Interesting)

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.

Re:Text displays in today's environment? (Score:2)

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.

Recommended Links

Softpanorama Recommended

Top articles

Sites

• Anti-Mac -- an interesting critique of MAC-style graphic interface
• Command-line shell versus Graphical User
• Linux GUI vs. Command Line
• Command line interface - Wikipedia Advantages of a command line interface
• InTheBeginningWasTheCommandLine - spack [dot] org
• ~tuomov – Software (page of the author of ion windows manager)

Etc

Society

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

Quotes

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

Bulletin:

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

History:

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

Classic books:

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 Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

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 Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019