|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
|
GUI with it's ability to display text using different fonts as well as to display 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 that idea of GUI interface from most common implementation -- mouse-based check-drag-drop type of interface that is most often associated with this term. It is just one possible implementation of GUI interface. Other implementations are possible as will be discussed below.
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. In other word they are not programmable. 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 much better "situational awareness" then pure (say, Unix shell style) command line interface. 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 should 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 the wrong directory and deletion of wrong files (or, God forbid, system directory like /etc in Unix) or making configuration changes on a wrong server are classic examples of loss of situational awareness. Many more can be listed ...
| 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). |
But there is also another fundamental problem with any rich, visually attractive GUI interface other then its inability to accommodate complex tasks, like movement of files from different directories in one operation. A primitive character based interface with fixed width fonts (often called "console interface") has interesting property, which is common for all minimalist interfaces. It stimulated creativity. Artists know well the saying "form liberates". In the same way severe restriction of 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, more complex capabilities (regular expression, etc) or both.
Most CLIs allow you to chain together commands (in Unix via pipes). Chaining is a powerful capability that is missing in check-drag-drop type of interface; 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 the 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 powerful confirmation 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
Orthodox interface can be imitated using multiple terminal windows in Unix. In this case one windows serves as command windows and has special PROMPT_COMMAND function written that created files that influence the behaviour of other windows.
From the GNU Bash doc page (http://www.gnu.org/software/bash/manual/bashref.html)
PPROMPT_COMMAND If set, the value is interpreted as a command to execute before
the printing of each primary prompt ($PS1).
- Dr Nikolai Bezroukov
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
Slashdot
Deep End's Paul Venezia speaks out against the overemphasis on GUIs in today's admin tools, saying that GUIs are fine and necessary in many cases, but only after a complete CLI is in place, and that they cannot interfere with the use of the CLI, only complement it. Otherwise, the GUI simply makes easy things easy and hard things much harder. He writes, 'If you have to make significant, identical changes to a bunch of Linux servers, is it easier to log into them one-by-one and run through a GUI or text-menu tool, or write a quick shell script that hits each box and either makes the changes or simply pulls down a few new config files and restarts some services? And it's not just about conservation of effort - it's also about accuracy. If you write a script, you're certain that the changes made will be identical on each box. If you're doing them all by hand, you aren't.'"
alain94040 (785132)Here is a Link to the print version of the article [infoworld.com] (that conveniently fits on 1 page instead of 3).
Providing a great GUI for complex routers or Linux admin is hard. Of course there has to be a CLI, that's how pros get the job done. But a great GUI is one that teaches a new user to eventually graduate to using CLI.
A bad GUI with no CLI is the worst of both worlds, the author of the article got that right. The 80/20 rule applies: 80% of the work is common to everyone, and should be offered with a GUI. And the 20% that is custom to each sysadmin, well use the CLI.
maxwell demon:
What would be nice is if the GUI could automatically create a shell script doing the change. That way you could (a) learn about how to do it per CLI by looking at the generated shell script, and (b) apply the generated shell script (after proper inspection, of course) to other computers.
0123456 (636235) writes:
What would be nice is if the GUI could automatically create a shell script doing the change.
While it's not quite the same thing, our GUI-based home router has an option to download the config as a text file so you can automatically reconfigure it from that file if it has to be reset to defaults. You could presumably use sed to change IP addresses, etc, and copy it to a different router. Of course it runs Linux.
Alain Williams:
AIX's SMIT did this, or rather it wrote the commands that it executed to achieve what you asked it to do. This meant that you could learn: look at what it did and find out about which CLI commands to run. You could also take them, build them into a script, copy elsewhere, ... I liked SMIT.
Ephemeriis:
What would be nice is if the GUI could automatically create a shell script doing the change. That way you could (a) learn about how to do it per CLI by looking at the generated shell script, and (b) apply the generated shell script (after proper inspection, of course) to other computers.
Cisco's GUI stuff doesn't really generate any scripts, but the commands it creates are the same things you'd type into a CLI. And the resulting configuration is just as human-readable (barring any weird naming conventions) as one built using the CLI. I've actually learned an awful lot about the Cisco CLI by using their GUI.
We've just started working with Aruba hardware. Installed a mobility controller last week. They've got a GUI that does something similar. It's all a pretty web-based front-end, but it again generates CLI commands and a human-readable configuration. I'm still very new to the platform, but I'm already learning about their CLI through the GUI. And getting work done that I wouldn't be able to if I had to look up the CLI commands for everything.
Microsoft's more recent tools are also doing this. Exchange 2007 and newer, for example, are really completely driven by the PowerShell CLI. The GUI generates commands and just feeds them into PowerShell for you. So you can again issue your commands through the GUI, and learn how you could have done it in PowerShell instead.
Anpheus:
Just about every Microsoft tool newer than 2007 does this. Virtual machine manager, SQL Server has done it for ages, I think almost all the system center tools do, etc.
It's a huge improvement.
PoV:
All good admins document their work (don't they? DON'T THEY?). With a CLI or a script that's easy: it comes down to "log in as user X, change to directory Y, run script Z with arguments A B and C - the output should look like D". Try that when all you have is a GLUI (like a GUI, but you get stuck): open this window, select that option, drag a slider, check these boxes, click Yes, three times. The output might look a little like this blurry screen shot and the only record of a successful execution is a window that disappears as soon as the application ends.
I suppose the Linux community should be grateful that windows made the fundemental systems design error of making everything graphic. Without that basic failure, Linux might never have even got the toe-hold it has now.
skids:
I think this is a stronger point than the OP: GUIs do not lead to good documentation. In fact, GUIs pretty much are limited to procedural documentation like the example you gave.
The best they can do as far as actual documentation, where the precise effect of all the widgets is explained, is a screenshot with little quote bubbles pointing to each doodad. That's a ridiculous way to document.
This is as opposed to a command reference which can organize, usually in a pretty sensible fashion, exact descriptions of what each command does.
Moreover, the GUI authors seem to have a penchant to find new names for existing CLI concepts. Even worse, those names are usually inappropriate vagueries quickly cobbled together in an off-the-cuff afterthought, and do not actually tell you where the doodad resides in the menu system. With a CLI, the name of the command or feature set is its location.
Not that even good command references are mandatory by today's pathetic standards. Even the big boys like Cisco have shown major degradation in the quality of their documentation during the last decade.
pedantic bore:
I think the author might not fully understand who most admins are. They're people who couldn't write a shell script if their lives depended on it, because they've never had to. GUI-dependent users become GUI-dependent admins.
As a percentage of computer users, people who can actually navigate a CLI are an ever-diminishing group.
arth1: /etc/resolv.conf
/etc/init.d/NetworkManager stop
chkconfig NetworkManager off
chkconfig network on
vi/etc/sysconfig/network
vi/etc/sysconfig/network-scripts/eth0 At least they named it NetworkManager, so experienced admins could recognize it as a culprit. Anything named in CamelCase is almost invariably written by new school programmers who don't grok the Unix toolbox concept and write applications instead of tools, and the bloated drivel is usually best avoided.
Darkness404 (1287218) writes: on Monday October 04, @07:21PM (#33789446)
There are more and more small businesses (5, 10 or so employees) realizing that they can get things done easier if they had a server. Because the business can't really afford to hire a sysadmin or a full-time tech person, its generally the employee who "knows computers" (you know, the person who has to help the boss check his e-mail every day, etc.) and since they don't have the knowledge of a skilled *Nix admin, a GUI makes their administration a lot easier.
So with the increasing use of servers among non-admins, it only makes sense for a growth in GUI-based solutions.
Svartalf (2997) writes: Ah... But the thing is... You don't NEED the GUI with recent Linux systems- you do with Windows.
oatworm (969674) writes: on Monday October 04, @07:38PM (#33789624) Homepage
Bingo. Realistically, if you're a company with less than a 100 employees (read: most companies), you're only going to have a handful of servers in house and they're each going to be dedicated to particular roles. You're not going to have 100 clustered fileservers - instead, you're going to have one or maybe two. You're not going to have a dozen e-mail servers - instead, you're going to have one or two. Consequently, the office admin's focus isn't going to be scalability; it just won't matter to the admin if they can script, say, creating a mailbox for 100 new users instead of just one. Instead, said office admin is going to be more focused on finding ways to do semi-unusual things (e.g. "create a VPN between this office and our new branch office", "promote this new server as a domain controller", "install SQL", etc.) that they might do, oh, once a year.
The trouble with Linux, and I'm speaking as someone who's used YaST in precisely this context, is that you have to make a choice - do you let the GUI manage it or do you CLI it? If you try to do both, there will be inconsistencies because the grammar of the config files is too ambiguous; consequently, the GUI config file parser will probably just overwrite whatever manual changes it thinks is "invalid", whether it really is or not. If you let the GUI manage it, you better hope the GUI has the flexibility necessary to meet your needs. If, for example, YaST doesn't understand named Apache virtual hosts, well, good luck figuring out where it's hiding all of the various config files that it was sensibly spreading out in multiple locations for you, and don't you dare use YaST to manage Apache again or it'll delete your Apache-legal but YaST-"invalid" directive.
The only solution I really see is for manual config file support with optional XML (or some other machine-friendly but still human-readable format) linkages. For example, if you want to hand-edit your resolv.conf, that's fine, but if the GUI is going to take over, it'll toss a directive on line 1 that says "#import resolv.conf.xml" and immediately overrides (but does not overwrite) everything following that. Then, if you still want to use the GUI but need to hand-edit something, you can edit the XML file using the appropriate syntax and know that your change will be reflected on the GUI.
That's my take. Your mileage, of course, may vary.
icebraining (1313345) writes: on Monday October 04, @07:24PM (#33789494) Homepage
I have a cheap router with only a web gui. I wrote a two line bash script that simply POSTs the right requests to URL. Simply put, HTTP interfaces, especially if they implement the right response codes, are actually very nice to script.
devent (1627873) writes:
Why Windows servers have a GUI is beyond me anyway. The servers are running 99,99% of the time without a monitor and normally you just login per ssh to a console if you need to administer them. But they are consuming the extra RAM, the extra CPU cycles and the extra security threats. I don't now, but can you de-install the GUI from a Windows server? Or better, do you have an option for no-GUI installation? Just saw the minimum hardware requirements. 512 MB RAM and 32 GB or greater disk space. My server runs
sirsnork (530512) writes: on Monday October 04, @07:43PM (#33789672)
it's called a "core" install in Server 2008 and up, and if you do that, there is no going back, you can't ever add the GUI back.
What this means is you can run a small subset of MS services that don't need GUI interaction. With R2 that subset grew somwhat as they added the ability to install .Net too, which mean't you could run IIS in a useful manner (arguably the strongest reason to want to do this in the first place).
Still it's a one way trip and you better be damn sure what services need to run on that box for the lifetime of that box or you're looking at a reinstall. Most windows admins will still tell you the risk isn't worth it.
Simple things like network configuration without a GUI in windows is tedious, and, at least last time i looked, you lost the ability to trunk network poers because the NIC manufactuers all assumed you had a GUI to configure your NICs
prichardson (603676) writes: on Monday October 04, @07:27PM (#33789520) Journal
This is also a problem with Max OS X Server. Apple builds their services from open source products and adds a GUI for configuration to make it all clickable and easy to set up. However, many options that can be set on the command line can't be set in the GUI. Even worse, making CLI changes to services can break the GUI entirely.
The hardware and software are both super stable and run really smoothly, so once everything gets set up, it's awesome. Still, it's hard for a guy who would rather make changes on the CLI to get used to.
MrEricSir (398214) writes:
Just because you're used to a CLI doesn't make it better. Why would I want to read a bunch of documentation, mess with command line options, then read whole block of text to see what it did? I'd much rather sit back in my chair, click something, and then see if it worked. Don't make me read a bunch of man pages just to do a simple task. In essence, the question here is whether it's okay for the user to be lazy and use a GUI, or whether the programmer should be too lazy to develop a GUI.
ak_hepcat (468765) writes: <[email protected] minus author> on Monday October 04, @07:38PM (#33789626) Homepage Journal
Probably because it's also about the ease of troubleshooting issues.
How do you troubleshoot something with a GUI after you've misconfigured? How do you troubleshoot a programming error (bug) in the GUI -> device communication? How do you scale to tens, hundreds, or thousands of devices with a GUI?
CLI makes all this easier and more manageable.
arth1 (260657) writes:
Why would I want to read a bunch of documentation, mess with command line options, then read whole block of text to see what it did? I'd much rather sit back in my chair, click something, and then see if it worked. Don't make me read a bunch of man pages just to do a simple task. Because then you'll be stuck at doing simple tasks, and will never be able to do more advanced tasks. Without hiring a team to write an app for you instead of doing it yourself in two minutes, that is. The time you spend reading man
fandingo (1541045) writes: on Monday October 04, @07:54PM (#33789778)
I don't think you really understand systems administration. 'Users,' or in this case admins, don't typically do stuff once. Furthermore, they need to know what he did and how to do it again (i.e. new server or whatever) or just remember what he did. One-off stuff isn't common and is a sign of poor administration (i.e. tracking changes and following processes).
What I'm trying to get at is that admins shouldn't do anything without reading the manual. As a Windows/Linux admin, I tend to find Linux easier to properly administer because I either already know how to perform an operation or I have to read the manual (manpage) and learn a decent amount about the operation (i.e. more than click here/use this flag).
Don't get me wrong, GUIs can make unknown operations significantly easier, but they often lead to poor process management. To document processes, screenshots are typically needed. They can be done well, but I find that GUI documentation (created by admins, not vendor docs) tend to be of very low quality. They are also vulnerable to 'upgrades' where vendors change the interface design. CLI programs typically have more stable interfaces, but maybe that's just because they have been around longer...
maotx (765127) writes: <[email protected]> on Monday October 04, @07:42PM (#33789666)
That's one thing Microsoft did right with Exchange 2007. They built it entirely around their new powershell CLI and then built a GUI for it. The GUI is limited in compared to what you can do with the CLI, but you can get most things done. The CLI becomes extremely handy for batch jobs and exporting statistics to csv files. I'd say it's really up there with BASH in terms of scripting, data manipulation, and integration (not just Exchange but WMI, SQL, etc.)
They tried to do similar with Windows 2008 and their Core [petri.co.il] feature, but they still have to load a GUI to present a prompt...Reply to This
Charles Dodgeson (248492) writes: <[email protected]> on Monday October 04, @08:51PM (#33790206) Homepage Journal
Probably Debian would have been OK, but I was finding admin of most Linux distros a pain for exactly these reasons. I couldn't find a layer where I could do everything that I needed to do without worrying about one thing stepping on another. No doubt there are ways that I could manage a Linux system without running into different layers of management tools stepping on each other, but it was a struggle.
There were other reasons as well (although there is a lot that I miss about Linux), but I think that this was one of the leading reasons.
(NB: I realize that this is flamebait (I've got karma to burn), but that isn't my intention here.)
|
|
|
As is the practice nowadays, we show you some screenshots to wet your appetite.These screenshots demonstrate various features implemented with Lua. No C code is used.
See here how to enable these features.
Fields
You can write your own fields in Lua.
Let's analyze what we see in the picture:
- This image shows some git-related fields. This saves you from having to do "git status" repeatedly.
- We also see here that the Size field was redefined (again, using Lua alone) to show commas (or some other means the locale rules dictate), to make it easier to read.
The git branch name is is displayed at the bottom of the panel (it's not a field). The working directory is dirty (we have local modifications), which is why it's displayed in red.
The When, Author, and Message fields tell us the details of the last commit of the file. For example,
arg.cwas last committed 22 days ago by Andrew. The commit's ID (shown at the mini status) is 8c88aa01ad.
The St[atus] field is the realy useful field here (and is probably the only field you'll want displayed, especially since it has little performance penalty). It's a two-character field showing the status of the file (see git-status(1) for the letters' meaning):
- We've modified
cons.handler.c.- We've renamed
help.htohelping.hand also modified it.- We've added
newfile.c(but not yet committed it).- We've created
output.html, which is not tracked by git.- The subtree under
man2hlptoo has been modified in some way, to which the**hints.On the right panel:
defs.jsis ignored (by being listed in.gitignore), and a few other files are not tracked by git (indicated by??). The working directory there is clean (displayed in green).More fields; BiDi
Note the drop-shadow effect for dialogs, and how the Sort order dialog was moved away from the center to make the screenshot more useful. This "pyrotechnic" is implemented with just a few lines of Lua code. No "code bloat" is involved here.
These fields are aggressively cached, so it's feasible to use them even on slow machines.
- This image shows some multimedia fields. We see the Durat[ion] of videos / songs, the Bi[trate] and, for videos, the Hei[ght] in pixels. These fields are sortable.
- The Name field was redefined to support BiDi languages like Arabic and Hebrew: the letters order is reversed and, for Arabic, character shaping is performed.
Visual Rename
Sometimes you wish to rename a bunch of files using some regexp. MC can do this but with MC it's like shooting in the dark: you don't know the names you'll end up with till you perform the rename, and then you may discover, to your dismay, that you'll be overwriting some files! Visual Rename solves this by showing you, as you type, how your files will end up. It also warns you if clashes (overwriting files) will occur. You can also rename files down a directory tree by "panelize"ing first.
You may even plug in your own code. No more wasting time on writing those little shell/ruby/perl script to rename files!
Also note the "Panelize" button. There's a special mode that makes Visual Rename act somewhat like a filter-as-you-type feature.
Filesystems
You can write filesystems in Lua. The following naive code:
local myfs = { prefix = "myfs", readdir = function () return { "one.txt", "two.txt", "three.txt" } end, file = function (_, path) if path == "one.txt" then return "Mary had a little lamb.\nHis fleece was white as snow." end end } fs.register_filesystem(myfs)results in:
You'll also find bundled filesystems for SQLite, MySQL and MHT. Editor
The editor too can benefit from scripting, as we'll see here.
Speller
A basic speller can be implemented in just 5 lines of code. The speller script shown here interacts with your actual speller via the aspell / ispell / hunspell / spell binary.
This is very different than MC's current approach of linking against a certain C library, an approach which deprives you of the freedom to choose a speller, and of the freedom to decide whether this feature is actually enabled (as it's a compile-time decision).
Note, in the picture, that misspellings are only highlighted when they occur in comments (and string literals). We certainly don't want "misspellings" occurring in the main code (e.g. "g_getenv") to be highlighted.
Linter
Linter for various languages. Visual Replace
The Visual Rename we've seen earlier also works in the editor, where it's known as Visual Replace. It lets you see all the changes in advance, making it a safe alternative to the potentially hazardous "Replace All". Function list
Shows a menu of your functions. Modeline
Modeline support. UnicodeData.txt; ruler; scrollbar
We see three features here:
- The unicodedata.lua script shows the UTF-8 bytes, and the appropriate line from UnicodeData.txt, of a character we're curious about.
- There's a ruler if you need to measure distances on the screen. It works anywhere, not just in the editor.
- There's a scrollbar at the left.
"Actors"
The idea behind the "modeline" feature -of embedding meta information in the text- can be used for implementing various creative ideas. Here we've embedded the names of the characters of a novel at the start of the text. Our "actors" script then colors them up. Males are in bluish color; females in pinkish.
Also shown here is our dictionary.lua script.
User Interface
We have an elegant, easy, and yet powerful API for creating user interfaces.
A game. In this picture we also happen to be editing the source code of the game. We can edit Lua code right inside MC and then ask it to reload the Lua subsystem when we want to see the effects of our modified code. We don't need to restart MC.
Notice, in the picture, several things borrowed from the JavaScript world: set_interval and on_click. Additionally, Lua is a dynamic language, which makes it possible to use different styles of programming.
Also note the scrollbar at the left.
Recently Visited Files; xterm titles
Here's a box showing you the files you've recently edited. This feature saves you a huge amount of keystrokes because you no longer need to navigate among directories. There's also a "Goto" button which makes this box an alternative to the "Directory hotlist" box.
Files you're currently editing are marked with "*". You can switch to them right from this box, which makes it a replacement for MC's "Screens" box.
Files edited in other MC processes are marked with "!".
You can even provide your own code to alter the list. E.g., you can add there files edited in Vim or gedit. Or you can populate it with all the files in your project.
You also see here alternative xterm titles. Note the terminal's three tabs: MC's builtin xterm titles would have wasted precious space. Here we have "[M] /path/to/dir" shown for the filemanager, and "[E] edited-file.txt" for the editor. You may customize this. E.g., you can add the process ID to the title.
Note that we're editing the "TODO" file in the left tab. Indeed, our Recently visited files box indicates (with a "!") that this file is being edited by another process.
Snapshots
Want to save the state of your panels? You have it: snapshots. This feature is somewhat like tabs, and somewhat like the "Directory hotlist".
Note the "sb" snapshot, which doesn't record a directory (indicated by
<none>). We use it to easily restore a sorting order and a custom listing format.The "p" snapshot, on the other hand, records nothing but directory paths (indicated by a missing
+).Calculator
Tired of running irb,python,ghci, etc. every time you need to evaluate some formula? Sure you are.Here's the solution. A calculator.
You're not limited to math formulas: any Lua expression works.
Find-as-you-type; clock
This image shows two accessories: ("broo" matches "Brooks" because the search is case insensitive unless you type an uppercase letter. If the search string isn't found, the "Search" box is painted in alert colors (typically red).)
- You can search in any listbox widget. Here we demonstrate this with the Directory Hotlist dialog, but it works anywhere.
- You also see a clock at the top-right corner.
Docks
You can inject your own widgets into the filemanager (this is just a "by product" of our fine user interface API). The ticker module injects widgets that show you the output of shell commands and have this display updated every X seconds.
In this picture we see two tickers. The top one (the reddish) shows some RSS feeds. The bottom one (the khaki) shows a random line from a text file (useful for people learning some [human] language and needing to improve their vocabulary, for example).
The user can easily improvise a clock by using a ticker, but there's already one.
Some other potential uses for this ability:
- A bar with extra information about the selected file or files.
- A tab bar.
Access-warning
We can inject widgets to the editor too. Here we use this ability to inject, besides a scrollbar, a label warning you about files you won't be able to save. (This label, as the scrollbar, doesn't come on top of the text: it's docked south of it.)
Scrollbar; filter-as-you-type
[May 23, 2015] mc^2 by Mooffie
A very important news. Attempt to add LUA support to MC.
- From: Mooffie <mooffie gmail com>
- To: mc-devel gnome org
- Subject: [ANN] mc^2
- Date: Thu, 7 May 2015 23:23:54 +0300
Hi guys!
I've just published a branch of MC with Lua support:
http://www.typo.co.il/~mooffie/mc-lua/docs/html/
See the "screenshots" lin k.
Hi guys!
I've just published a branch of MC with Lua support:
http://www.typo.co.il/~mooffie/mc-lua/docs/html/
See the "screenshots" link.
Also see the "other documents" link for background (especially "HISTORY").
Many, many tickets can be solved with mc^2, but I don't want to spam the ticket queue with my posts, so I've prepared a list of some such tickets (see "other documents" -> "TICKETS").
(But in a few tickets I *will* comment: in tickets I believe a constructive discussion could ensue, or where I feel people are truly in need of a solution.)
==
Now, I guess I'll be attacked for one reason or another. Let me save your time by attacking myself for you:
==
Q: "Is this a 'fork' of MC? Are you trying to split the community?"
A: No, this is not a "fork" (as per Wikipedia's definition). It's intended to be "food for thought" for the MC community. My hope is that eventually the principle behind mc^2 will be adopted by MC.
==
Q: "Is seems that you've invested a lot of time in this. Gosh, why waste human resources?! Especially on something that nobody's going to use?"
A: The time I "waste" here is negligible in comparison to the time and efforts wasted by tens of people who have tried to contribute code to MC over the years.
The principle behind mc^2, if adopted by MC, is going to put an end to this waste of human resources.
==
Q: "But why use Lua?!?! Why not pick the language that starts with 'P'?! Why not make it work with any language?!??!"
A: Let's not talk about languages/VMs *right now*. Please, as much as it's tempting.
Right now, the language is not the issue. The issue is the principle, of having some extension language.
The language/VM is obviously something everybody will have something to say about. You will. But not now.
If every passerby here will now emit his "2 cents" opinion/rant, it will kill the vision/project. It will start a Holy War. It will derail the discussion from the mainroad to the gutters. It's the least constructive thing that could happen. It means death.
In the future, when we know the principle will be regarded favorably by MC's maintainers, we could open this issue and discuss things.
One thing's for sure: You can't give an opinion about the subject without considering it for at least a week (or a month, I'd say). There are various facets to consider. There are threads of thoughts to be picked and discarded. There are insights to be acquired. You can't just barge in with "use Python!!", "use Parrot!", "use GObject!". As the Chinese saying goes, "Opinions are like belly buttons: everybody has one". It should take more, much more, than an "opinion" to affect the discussion.
So, again: let's not talk about languages now.
(For the record: I recorded my reasons for choosing Lua in "other documents" -> "HISTORY".)
Also see the "other documents" link for background (especially "HISTORY"). Many, many tickets can be solved with mc^2, but I don't want to spam the ticket queue with my posts, so I've prepared a list of some such tickets (see "other documents" -> "TICKETS"). (But in a few tickets I *will* comment: in tickets I believe a constructive discussion could ensue, or where I feel people are truly in need of a solution.) == Now, I guess I'll be attacked for one reason or another. Let me save your time by attacking myself for you: == Q: "Is this a 'fork' of MC? Are you trying to split the community?" A: No, this is not a "fork" (as per Wikipedia's definition). It's intended to be "food for thought" for the MC community. My hope is that eventually the principle behind mc^2 will be adopted by MC. == Q: "Is seems that you've invested a lot of time in this. Gosh, why waste human resources?! Especially on something that nobody's going to use?" A: The time I "waste" here is negligible in comparison to the time and efforts wasted by tens of people who have tried to contribute code to MC over the years. The principle behind mc^2, if adopted by MC, is going to put an end to this waste of human resources. == Q: "But why use Lua?!?! Why not pick the language that starts with 'P'?! Why not make it work with any language?!??!" A: Let's not talk about languages/VMs *right now*. Please, as much as it's tempting. Right now, the language is not the issue. The issue is the principle, of having some extension language. The language/VM is obviously something everybody will have something to say about. You will. But not now. If every passerby here will now emit his "2 cents" opinion/rant, it will kill the vision/project. It will start a Holy War. It will derail the discussion from the mainroad to the gutters. It's the least constructive thing that could happen. It means death. In the future, when we know the principle will be regarded favorably by MC's maintainers, we could open this issue and discuss things. One thing's for sure: You can't give an opinion about the subject without considering it for at least a week (or a month, I'd say). There are various facets to consider. There are threads of thoughts to be picked and discarded. There are insights to be acquired. You can't just barge in with "use Python!!", "use Parrot!", "use GObject!". As the Chinese saying goes, "Opinions are like belly buttons: everybody has one". It should take more, much more, than an "opinion" to affect the discussion. So, again: let's not talk about languages now. (For the record: I recorded my reasons for choosing Lua in "other documents" -> "HISTORY".)
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)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.
Kurt
by 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:x by 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.
feldicus
Re: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.
[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.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.
[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.
Recommended Links
Google matched content
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
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. 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 to buy a cup of coffee for authors of this site Disclaimer:
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: February, 10, 2021
