It is not fashionable nowadays to speak of the merits of the command line, in an age where things like streaming video and Aqua are an integral part of our daily life. However, I do not think that typed-in commands must necessarily be consigned to the dustbin of computer history. Of course, I am not suggesting that we all drop X and Windows and pretend like we are living in the early eighties. The command line interface still has much to offer us, and many of its benefits simply cannot physically be emulated or even replaced by graphical ones.In this article, I will be analyzing the specific properties that make the command line unique and irreplaceable. I will likewise analyze the graphical UI’s features–though only giving it a cursory look, since I assume my audience does not need to be persuaded to make the most of its video hardware. I will be looking at the Unix shell, since it is the most full-featured and powerful of such interfaces (DOS, of course, had very few features worth talking about; it must be given its due, though–it brought millions of people into computing). I will be looking at GUIs on a more general level.
Benefits of the CLI:
– The structure of Unix and of its shells allows powerful mechanisms of piping and redirection to work. Anyone who has even done administration tasks in this environment, even simply on a desktop machine, knows that things like sed and sort are a necessity. What makes this unique is that it is universal–there is no command whose output cannot be redirected somewhere else, whether to a file or to another command. It is conceivable for a programmer to, say, add an “Edit this output in Notepad” option to a number crunching program. But to make an entire graphical userspace have universal interfaces for redirecting output is truly a titanic task (KDE and Kparts have made good progress, but as we all know, the free Unix GUI is badly fragmented, making universality practically impossible). A good part of the difficulty of doing this comes from the heterogenity of the data being operated upon, as well as the inherent multifunctionality of graphical interfaces–although cut and paste is a good thing too.
– The world of the Unix console, as opposed to its desktop, is rather unfragmented. POSIX, that mighty juggernaut of standardization, has ensured that porting command-line programs from one Unix to another is a relative breeze. Especially remarkable is the fact that it can also function for wholly un-Unix systems–like the BeOS (to which I believe the E.i.C. of this site has ported a number of programs) or QNX, or even Windows, all of which have rather complete suites of GNU programs (in the latter case, two). Porting a program that uses graphics, however, is sometimes difficult even among Unices–especially given the varying degrees of freeness of graphical Unix programs and libraries (Unix’s command line has largely abandoned that conflict, since the source for the vast majority (all?) of its core programs is available through BSD).
– Although today’s hardware largely renders this point moot, command-line programs incur much less size and speed overhead than their graphical counterparts. In fact, bash itself, at 600-odd kilobytes, is likely to be one of the largest command line programs one runs. By “overhead” I mean exactly that–the amount of resources consumed that is not strictly necessary to the task at hand. So, for instance, it stands to reason that GCC will soak up more memory and CPU than KMenuEd, but that is inherent in its function. Also, when one recycles old hardware for routers and minor servers, it would be a waste to put a graphical desktop on it. This is one of the main reasons that Linux (*BSD too) is popular for reincarnating 486s–it can be easily administered via command line.
– Remote access is a necessary element of such administration. There is, of course, VNC and PCAnywhere and what-have-you, but of those, only VNC is as cross-platform and simple as SSH. An SSH session essentially can start from anywhere, since there are clients available for a huge number of platforms. Also, the OpenSSH folks are serious about security: encryption allows one not to worry about passwords. VNC, though, unless tunnelled through SSH, offers no security at all. Textual information is also much smaller than graphical, obviously making remote connections less of a pain in the neck. It is extremely difficult to get a tolerable speed with VNC, whereas with SSH the speed is near local. The last element is antiquated, but nevertheless powerful–serial consoles. There simpty is no better tool to administer a temporarily offline headless server.
These are some of the virtues of the command line. There are other things specific to shells that make life much easier, but these are the important ones.
Benefits of the GUI:
– An important benefit is the display of dynamically modifiable abstract information (Short example: Open a file manager and delete a file, then make sure it is deleted: three shell commands vs. a mouse click.). This means web browsing, spreadsheets, word processors, etc. are possible. This is available for the console with Curses and Turbopower and that sort of thing, but I do not think that these libraries belong to the CLI proper.
– Of course, aesthetics. It is much more pleasant looking at Luna than at a serial console (I think the Luna widgets are the coolest thing since GEM, but that’s just me), and I think a good reason for the migration to GUI is the prettier and more natural feel. It is no accident that Unix started recovering from its slump when high-quality desktop environments (Gnome, KDE, NOT CDE) became available–because of Linux.
– Modern computing is very much focused on media, and that is naturally only done with graphical environments. Framebuffers are inadequate for this kind of function.
– The graphical desktop allows true multitasking (for the user) to take place. Switching virtual terminals is a poor replacement for switching windows, because windows allow more than one program to show its output at the same time, resulting in much increased efficiency and flexibility.
I think I have made a case for the continued existence of the command-line interface. I hope there will be a place for the little blinking cursor (in a window, all right) in whatever fancy new desktop wins the wars.
A note: I do not necessarily consider “user-friendliness” to be a necessarily valid argument. In ’91 an office worker whose computer ran Unix was expected to know things like troff, and it was perfectly natural–the company determined what was friendly for him. “Joe User”, like a normal Russian worker, is too often something completely fictional. Remember that switching from familiar DOS to unfamiliar Windows was also hard for many.
About the Author:
Greg Afinogenov splits his time between America and Russia. Computers for him are a hobby–his main study is history.
As a general overview the article is quite fair. What I think is the most important point, and one the author touches upon, are the issues relating to availability, usability, and usefulness. For example, with Linux we have a high degree of GUI availability, medium level of usability, and low level of usefulness, as far as the average user is concerned. An interesting comment made in another thread touched on the relative popularity of BeOS versus Linux in Japan, for these same reasons. The issue raised by this is who is designing what for whom. CLI’s are inappropriate for the majority of users who just want to get stuff done. I’m also of a mind that too much systems administration is CLI bound. Perhaps it’s time to move beyond the CLI versus GUI debate and start building systems that don’t need the CLI.
I didn’t use a GUI for about the first 4 years of my computing experience so I got pretty used to the CLI. People who complain about KDE have never suffered through MSDOS print files, PDP11 bootstrap sequences (flicking switches), 80×25 monochrome screen resolutions or teletype terminals on mainframes.
Even XP needs a fair bit of CLI to get to the nitty gritty of many configurations such as advanced disk tools. The reality is that it is much easier to open the command prompt and type chkdsk rather than than going through half a dozen folders in the start menu and clicking.
Installing Ximian desktop or switching to administrator is a breeze …I’d rather type su than use XPs fast user switching anytime.
That said both GUI and CLI tools should be available for almost all tasks.
I’d rather type su than use XPs fast user switching anytime
Or you can right click on the app you want and select ‘Run as..’
replying to Charles E Hardwidge:
you said to start building systems that don’t need the CLI.
well, i hope this system doesn’t need a system administrator
Why do most articles like this concentrate on old CLIs? Some ppl have had really bad times with things like dos, but the world isn’t like that any more. Modern non-gui programs are well designed and work well. Mutt, vi, bash – they all beat their gui counterparts hands down.
> – Switching virtual terminals is a poor replacement for
> switching windows,
Rubbish. Have you never used screen?
Of course, there is still the place for guis. When you don’t really know what you’re doing and are only going to do it once, they’re great. Some of the gnome system tools are great. I use openoffice instead of gnuplot since I rarely have to use it. It’s just a shame that so many ppl suffer with guis because they can’t be bothered spending a few minutes to get started with the non-gui alternatives. It’s a one time hit, not like the continuous pain of how much effort and time it takes for people to do things with windows explorer and gui email programs.
The Unix-Hater’s Handbook (out of print, free pdf available online, search for it on Google) is full of anecdotes of problems that occur when you try to treat everything as a stream. (For the uninitiated, the “everything as a stream” concept is tightly coupled, or intermingled, with the CLI shell.) Check out chapter 8 on “csh, pipes, and find” for some examples.
I’m not saying the CLI is bad, I’m just saying CLI tools themselves have limitations in the way they are currently implemented (although some of those bugs have hopefully been fixed by now, but I’m too scared to check).
As the author of this article has stated, GUI scripting tools also have their limitations, one of which is the difficulty in making them as flexible and powerful as their CLI counterparts. So while there’s room on both sides to grow, I think Charles E Hardwidge is right on the money in his comment about moving towards systems that don’t need the CLI. It’s the next evolutionary step in shell programming.
Microsoft tries to improve its command prompt in eacht major WIndows release. Remember vbscribt? Command console? Safe mode with comand prompt? And so on…
The command line mode has it’s own use, especially for system admins.
To prove my point:
M$ has creted a network scan tool to see which hosts have crippy RPC implementations (unpatched). You need the RPC patch to protect your Windows machine against the Blaster virus.
The tools uses a command line interface. It’s a console app.
take a look for yourself:
http://support.microsoft.com/default.aspx?scid=kb;en-us;826369
The CLI is far from dead. It’s even USEFUL BECAUSE NORMAL USERS DON’T UNDERSTAND IT, so they will not touch tools only meant for sysadmins.
CLI is still useful in windows.. for changing the extension if you don’t want to have them visible all the time.
in the command line in xp.. you can type half a command hit tab, and it will finish the rest..
so if you want to delete a wierd file name.. you can type del vbse then hit tab. .and it will finish the rest of the filename for you. or if you want to change to a directory, like desktop.. you can type de then tab. its kinda nice.. to bad it diddn’t do that during dos days hehe
CLI is simply a better choice for certain tasks, GUI for the others. Right tool for the job.
I always liked that the Amiga’s default environment was fully a GUI but a CLI in a window… the desktop was just another app. That to me gave the greatest flexibility, the best of both worlds. Most modern OS’s do this now to some extent, though some do it better than others 🙂
> I’m not saying the CLI is bad, I’m just saying CLI tools
> themselves have limitations in the way they are currently
> implemented (although some of those bugs have hopefully been
> fixed by now, but I’m too scared to check).
Well… I can show you about 117 things which I can do faster in CLI than you can in GUI.
Don’t get my wrong.. I like the GUI, but I can’t live without a decent shell.
I have notived that I have different usage paterns though. In BeOS I use the GUI Tracker a lot. In Linux I hardly use such an application at all. I guess the reason is the nice clean integrations between the filesystem and the Tracker in BeOS, and the fact that there’s more powerful CLI tools on Linux (mostly because I haven’t botherered installing them on BeOS).
There’s a place for the GUI and there’s a place for the commandline.
I work as a programmer and I use vim for typing my source code. I can have as much xterms on my screen as I need, some of them running on remote computers for compiling stuff on another Unix platform.
For web-browsing and e-mail I usually use Mozilla and dillo, because web-browsing is much more appealling in graphics mode.
But sometimes I use lynx, too. Mostly when I have to remotely administer a computer and have to download something. I go to the page I need to download from with mozilla on my local PC and copy the url to the CLI on the remote machine starting lynx and download the file on the remote machine.
I think it is good practice that for a certain task both a command-line and a GUI program is available.
I also think it is good practice to program in such a way that you can separate your functionality from the parts that implement the GUI.
If your program can support both a CLI and a GUI, your program is much easier to port to a new GUI in the future, easier to debug, more robust and maintainable because you clearly separate different tasks within your software and more flexible because you can use it’s engine under water from other programs through the CLI.
I will be looking at the Unix shell, since it is the most full-featured and powerful of such interfaces
You obviously meant to add ‘still in common use today’ at the end of that sentence. While I never used a Lisp Machine, using Common Lisp convinces me that they must’ve been so much better than Unix it isn’t funny.
VNC, though, unless tunnelled through SSH, offers no security at all.
So … tunnel it through SSH. Yours is a non-argument. I’d rather tunnel VNC through SSH than have them implement their own encryption with a dozen bugs to be fixed for every bug in SSH.
you said to start building systems that don’t need the CLI. well, i hope this system doesn’t need a system administrator
I’m of the opinion that far too many systems are designed from the outset to require a low/high level systems administrator when better design might do away with the role. Let’s spend less time managing and more time doing.
So while there’s room on both sides to grow, I think Charles E Hardwidge is right on the money in his comment about moving towards systems that don’t need the CLI. It’s the next evolutionary step in shell programming.
I’ll name it CLICK! Command Line Interface Concept Killer!
>The world of the Unix console, as opposed to its desktop, is rather unfragmented.
Yes the “same” commands exists everywhere, but they have usually different option or different corner cases, fortunately the GNU version of these tools are available everywhere, but still.
The options are unfortunately very different: you want to have the version number, is-it -V, -v, –version or even something else?
The help files are in which format: man pages, info pages (beurk), HTML files, etc..
Are you tried to parse a simple ps output? It is quite complicated!
The text format used by the pipe has a main advantage that it is simple, but it also means that you have to continue reparse the output of the commands.
I’m wondering if a ruby terminal could be interesting, where you have the direct equivalent of each normal command: ls, ps, etc and each command would have a special options to be able to chain more easily the commands: ps –ruby would output a hash table, which could be easily used after.
Comments?
> Perhaps it’s time to move beyond the CLI versus GUI
> debate and start building systems that don’t need the CLI.
I couldn’t agree more. CLI is fine (I use it a lot), but for Linux to make a firm stand in the desktop market, GUI (for administration) is a must have. But just GUI is not enough.
When targeting the desktop market, one must take into account, that most of users in this market are computer illiterate. For them even GUI is a scary monster, that they fear, and won’t go near. A simple, wizard driven GUI interface is what is needed for them.
Of course this doesn’t mean that there is no room for CLI in Linux (or any OS). CLI is and should always be an integral part of any OS. But it should be a tool for power users and sysadmins, and not a requirement for the inexperienced.
Evolution is a naturally occurring process that aims to improve things and make the better. I do realize that not all change is for the better, but it’s still better then no change at all. Look at humans, from caves to houses, which make for a much more comfortable living, from rocks to hi-tech tools that make as more productive. But despite all that, you can still live in a cave and use rocks if you wish, it’s a matter of choice and that is from what I understand the power of OSS, the freedom to choose.
I hope I didn’t get too carried away.
BTW: CLI and GUI refer to (CLI|GUI) administration tools.
Does anyone remember the DOS telecommunications program called Telemate that was popular back in the DOS days?
Not only did Telemate have fancy things under the hood like its own multithreaded kernel (allowing for background tasks like file transfers even under DOS) and its own DOS prompt emulator, but it also had what could only be described as a text-mode GUI, complete with overlapping resizable windows, scroll bars, and both keybaord and mouse controls.
That was over ten years ago, and it’s not alone in being a text-mode program with a relatively sophisticated interface.
Right now, I’m using a text-mode web browser to write this message called Links (no, not lynx — the links browser shows frames and even general web site text colors PROPERLY on an 80×25 console screen), and it’s a text-mode program which command-line options and the whole works, but it also has a set of drop-down menus and even mouse support for those who prefer not to memorize keystrokes.
Same with the text-mode FTP client I use here under various platforms (NFTP). It has menus and mouse support, and it lets me select files via point-and-shoot just like a GUI program. But it isn’t. It’s all text.
Even the command shell that I use here under OS/2 (4OS2, a now-freeware sibling of the of the fairly popular commercial 4DOS and 4NT shells by J.P. Software) has a nice online help system and allows for a relatively intuitive point-and-shoot interface for almost ANY command via the SELECT command, has a nice visual command history selection box via the PgUp/PgDn keystrokes, and a visual program selection dialog via the F7 key. You don’t have to know the name of a program to run it from 4OS2 any more than you do in a GUI.
Features like pull-down menus, mouse support, and online help make the CLI pretty darn user-friendly in my book, at least as long as the user in question gets over their irrational fear that many people seem to have about command lines.
Of course there is still a place for the CLI – it often provides fadster access to tools than the GUI. On the other hand, I don’t think that comments about poorly designed GUIs are really an argument for CLIs – they are an argument for better GUIs.
For example,
>The CLI is far from dead. It’s even USEFUL BECAUSE NORMAL ?
>USERS DON’T UNDERSTAND IT, so they will not touch tools
>only meant for sysadmins.
Surely, a better way to make sure “normal” user don’t touch the admin tools it to provide a mechanism for the sysadmin to lock users out of these tools (whether GUI or CLI), rather than relying on user ignorance.
>CLI is still useful in windows.. for changing the
>extension if you don’t want to have them visible all the
>time.
…or provide a decent way of changing extensions wihin the GUI. Or better still, do away with these extensions *altogether* in GUI mode, and provide a better way of managing a file’s type. The close coupling between a file’s name and its type is actually counter intuitive. I have often seen users chane a file’s extension assuming that its type would “magically” change as well. Personally, I think that a file’s name and type should be treated as separate items of metadata about a file, in the same way as a file’s name has nothing to do with its size or modification date.
Finally, wouldn’t it be great if more tools operated in both GUI and CLI modes, where the same executable could be invoked in both modes?
Regards,
Kram II
As Arend pointed out, use the right tool for the right job.
I am surprised noone has mentioned Jef Raskin and The Humane Environment (THE).
THE is a command-line-esque environment which is very modular (like GNU apps in many ways) in it’s ideology.
Raskin – who worked on the Macintoshes desktop metaphor environment – has later found that the desktop metaphor is far from the holy grail.
Instead he says that for some things, a text input control system (with more visual feedback than a simple command line) is much better suited than a mouse, and for some things (like drawing) a mouse is (obviously) far better than a keyboard.
The idea is that it shouldn’t be necessary to reach for your mouse when using your keyboard, and that it shouldn’t be necessary to reach for the keyboard when using the mouse.
This is – in principle – implemented in windows, since you can use the keyb only or the mouse only, but this is not what Raskin is talking about. Obviously, if you are going to get anything done in windows, you need to use both your keyboard and your mouse.
Raskin has created THE as a new type of interface.
http://humane.sourceforge.net/the/
Unfortunately I can’t try it, since it’s only available for Mac (last I looked at least). It sounds like a good idea though.
And to add my own $0.02 worth, I certainly agree that the CLI has a place in this world. It suffers from the flaw that you have to remember the commands, but in comparison with mousing around you can do a very wide range of tasks extremely fast without a bunch of mucking around.
I use the win-r shortcut in windows more than I use the start menu. I have a script dir in my path, and in that script dir I place shortcut scripts for all programs I use a lot. Then I can launch photoshop with win-r-PS-enter, which is a hell of a lot faster than trudging through the menus.
I also have a bloated Quicklaunch bar, but that quickly becomes uselessly cluttered.
>> I’m also of a mind that too much systems administration is CLI bound. Perhaps it’s time to move beyond the CLI versus GUI debate and start building systems that don’t need the CLI.
>>
Too much sys admin is cli-bound?? I hope you are kidding. You can see them copying more and more of Unix Cli in their windows servers.
If Unix ever gets to the point where a certain task can only be performed on a GUI, it would have lost a HUGEEEE part of its useability. As a system admin, the times when I want to be clicking are few and far-between. Every app should be built in such a way that it can be completely managed from a CLI. A GUI on top should be an extra. Of course, that doesn’t invalidate the usefulness of a GUI for cetain desktop uses, like browsing. The point is that a GUI should as much as possible always be built on top of a CLI. Buidling an internally GUI-driven OS is greatly unuseful.
And for those complaining about the implementation of the CLI in Unix, well, you are looking at tons of years and experience. Use it. Or make it easy for yourself, by learning a simple scripting language. With justPerl and expect, for example, you don’t need to know the difference between a cshell and bash.
If you really want to learn about the power of the Unix command line, there’s no better way than browsing through “Unix Power Tools” from O’Reilly. It is a unique book, after the introductory chapter the rest is arranged as semi-hypertext so you can browse to whatever tips you are interested in easily. It also has some information in it posted in Usenet when it was still a use-ful place.
The latest 3rd edition is rather expensive at about $70, but used editions of earlier versions should be affordable from various online bookstores or eBay. (I own the 2nd ed, but have heard the 1st edition is the best because it includes a special chapter on awk that was removed in favor of a Perl-coverage stub.)
Why not build a system that combines the best of traditional GUIs and CLIs? Something that can accept complex commands entered in a command language (which is what a CLI really is) and displays the results graphically (which is easier for the brain to parse if done right)…
Too much sys admin is cli-bound?? I hope you are kidding. You can see them copying more and more of Unix Cli in their windows servers.
Now that you mention it, I heard that Microsoft is developing a GUI-less version of Windows Server. I don’t know if that rumor is true, and I sadly don’t have any source to back my claim, but I guess that a GUI-less version would be better and more efficient than a CLI-less one.
I’m not sure about Ruby, but there is a command line shell that uses Python which is kind of similar and surprisingly powerful: iPython at http://ipython.scipy.org/.
With this, a user can enter the normal shell commands (bash commands I believe), but it also acts as a Python interpreter so you have a scripting language that is more powerful than bash’s.
The difference boils down to the difference between free recall (CLI) and forced choice recall (GUI).
In free recall you have to pluck it out of your brain when it is needed without any stimulus to aid the process. Forced choice forces you to choose from a menu of choices the tradeoff is that a menu must be of a limited length to be useful therefore the options are limited. Your brain is essentially the limit in free recall.
Now in free recall you have a lot of choices but they only present themselves if you are using the system often and reinforcing the memories on a constant basis, stop using them for a while and they will start to decay. So if you are constantly using a command line interface it can be a much more powerful option. This is what leads to the power user image associated with CLI. However if you stop using it for a while you are forced to resort to GUI like tactics such as man pages and other references which slow the process down as the memories need to be refreshed
The GUI side is better in more general uses. In situations where the memories are not constantly refreshed and therefore are better suited to everyday needs of most people. Most people are not power users and do not want to be as they have other professions that are better served by spending their time doing those professions rather than using their learning resources on remembering commands. The waters are further muddied here to as often GUI people who use programs a lot also resort to free recall (or command line like) behaviour such as shortcut keys
So as with most things things it is a horses for courses division, both have valuable attributes and areas to which they are better suited and in both approaches there are drawbacks.
>>People who complain about KDE have never suffered through MSDOS print files <<
I have never understood what was supposed to be so difficult about ms-dos. There are only about ten commands most users would need, and they are all *so* complicated.
For example, if you want to print a file:
PRINT filename
Oh my god! You would have to be rocket scientist to understand that. To delete a file, you need the extrodinarily difficult command:
DEL filename
I guess it would take about a week for most people to understand that?
You should always use what works the best for you. I started my computer career in the very early 80’s (1982), and back then, CLI was the only choice. I didn’t use my first GUI until 1992, when I bought an 80486-33 with Microsoft Windows 3.1. Even then, a large part of my work was done on the command line. It just made sense to use that for system administration.
I have done a fair amount of remote administration of *nix boxes in the past several years, and for that, CLI remains king. A little SSH, a little VI(M) and you’re golden ;-).
When it comes to word processing, spreadsheet manipulation and graphics work, I naturally turn to a GUI. It only makes sense to use the tools that work the best for the job at hand.
Days after I installed Linux on my dual-boot machine, my wife said that I spent too much time in the terminal :-)))
Even though my Redhat box booted with graphical interface, most of the time I was sitting with a Gnome or KDE terminal.
Why don’t all GUI’s simply have a command line right in each window, just like all browser’s have have a place to type the URL???
(stand by for retarded replies that miss the point)
No, no it’s not. For about 97% of computer users out there Aqua is just the Spanish word for water.
In my world, that would imply that all app commands would be mapped to commands, which would make it so much easier for people to script different apps.
Like with Arexx on the amiga
Maybe I’m missing something, but I always find navigating through dirs, and copying files to be a real hassle in CLI.
In CLI, instead of natigating through recognition, you have to recall what the folder names are call, with the correct case, various tabs and “ls”, before you can get to the dir you want.
When copying, you have to remember the dir structure, how many level up is it, then back down to some other dir, with all the exact spelling. Don’t even think about selecting only some of the files in a dir, but not others.
While in Windows Explorer, it’s ctrl+click the files you want, ctrl+c, then to the destination folder and ctrl+v. Folder names are done by recognition rather than recalling.
To make it worse, these are operations that you do the most while using a computer.
> While in Windows Explorer, it’s ctrl+click the files
> you want, ctrl+c, then to the destination folder and ctrl+v.
well, the CLI version of this is better with patterns, when you can grep for a certain pattern in the filenames or something, so it’s not that good.
But if you want to do something other than cut’n’paste with the files, that’s when you’ll notice how the CLI is superiour;
say you want to convert all the files that match /blah*.gif/ and /pic(d+).gif/ into .jpg files and move them to the ~/pics/ folder.
show me your GUI alternative to ls/grep/convert/mv and how much work on your part does it take.
As a poster before me said: why not combine them?
Let’s analyze that CLI means command line interface, GUI means graphical user interface, what about a command driven graphical user interface (AFAIK THE is somethimg like that)?
At least the biggest disadvantages of both GUIs (flexibility, reusability) and CLIs(memorization, data representation) is by design, not per se.
Yes, those are easier with CLI, but they are no way a task that you do as common as the simple dir navigation and file copying that I described.
Often when you’re copying some files within a dir, they don’t have a pattern. If the filename starts with something similar, then they’re group together in Explorer anyway.
Along with the ability of grouping files by modified date/type/size/duration/dimension, it can do most of the sorting that you’ll ever need most of the time, that using regex won’t be any faster. Sure, when the need for regex comes, it’s faster, but that doesn’t happen that often.
Again, simple moving/copying files from one dir to another is way more common than renaming a perfectly good GIF file to a .jpg extension.
So, no doubt when doing slightly obscure tasks like the one you mentioned, CLI is better, I never disagreed with that, but a person’s computing experience largely consists of pretty standard tasks.
> renaming a perfectly good GIF file to a .jpg extension
I wasn’t renaming..
I was just converting very old pr0n into JPEGs
😉
for it depends on what the compooooter is doing, if it is just a file server then CLI is the way to go, personally i prefer GUI but both GNOME & KDE are kindof resource hogging (no worse than Windoze) so i install a linux distro with only twm and run my apps thru xterm…
ICEwm is progressing nicely
No offense but not everyone wants to run graphics mode, and not everyone needs a pacifier^H^H^H^H^H^H^H^Hmouse to get their job done. Lets face it there are tons of applications out there that lack useful keybindings ( EI: UNIX realplayer ), and reaching out to search for a mouse can really be a time killer. The only way that anyone could ever hope to replace/kill the CLI is by allowing users to maximize their effeciency without touching a mouse. Even so a GUI still has a high over head that alot of system admins don’t need( or want ), a CLI is a saner choice for servers, programming, and file management. Just some thoughts.
>show me your GUI alternative to ls/grep/convert/mv and how
>much work on your part does it take.
Again, just because current GUI’s are bad at something, that’s not to say that a GUI *couldn’t* implement it.
Personally, I’d love to see GUIs implement something like this, ideally with a graphical mechanism to help people build their selection query. You could even have the GUI provide a list of the selected files as you build your query, so you know exactly what you are going to get.
Regards,
Kram II
I think Megol got this right. Why would you ever want to limit your options, even if you don’t use them all. I say let’s have as many “tools” as possible.
The essential point of modern operating systems is not that GUIs are everything. In older systems, it is not true that the CLI is everything.
Some things, such as fast directory navigation are easier with a GUI and others, such as greps are better with a CLI. These are admittedly simple and poor examples, but I’m having my lunch. And yes, I’m using web browser keyboard navigation, because then I can just use one hand while I eat, and not have to move back and forth to the mouse.
Ultimately, however, the two interface methods are complementary. The CLI, fundamentally is very basic. When creating the most simple of applications, it is ideal. You don’t have to deal with widgets or event handling or anything complex. At the same time, GUIs can grow from these applications. It should also be mentioned that building GUI applications requires being able to spew out messages to helpfully debug, often. The command line is ideal for that. Otherwise you have to use a heavyweight debugger (which does the same thing, or write lots of extra widgets, objects and code to be able to report your messages.
Neither the GUI nor the CLI is perfect and they exist in harmony to each other.
To be honest, my effectiveness at work would halve if I didn’t have Konqi with the embedded terminal emulator at the bottom of the window. I get all of the GUI benefits and things that can only be done easily with the CLI can be done instantly too.
Take a modern language as a base. As a minimum the language must have built-in support for lists. Lambdas would also be nice. Python has both.
Now add some Visual Studio style syntax highlighting and code completion for function names *and* parameters, and some popup help for the parameters.
Combine this with some easy to use functions for day to day tasks, and you have something really cool.
There could be a simple version that runs in a terminal and a more complex version that has the above-mentioned popup-help, syntax highlighting, code folding and so on…
I really hope that somebody is working on something like this. I love the concept of the CLI, but I should not have to remember a million different and inconsitently named command line parameters and use an antiquated language like bash…
Personally I think the computer should have both so that people can use the tools that best suit their style.
I prefer the GUI for 2 reasons.
1) If at the CLI you don’t know the command you need, you’re screwed. It’s not user inutitive and the help menus aren’t often complete enough for a novice to use.
2) At the GUI, you have a list of options presented to you and can often see several ways to approach a problem.
Sure the CLI is hyper flexible, but the learning curve is Everest like.
IMO, both are needed as neither suit all people or purposes. Why limit yourself to just one useful tool, when both can be provided? Some things are easier to do in CLIs than in GUIs, and there are other things that are easier to do in GUIs than in CLIs. It’s just the way things work.
Bash is a great shell, if you want the VS stuff stick to M$. As far as extending bash as a language, it can already do anything you want it to do… it’s a program with the purpose of managing other programs therefore it’s strength lies in the ability to create a pipeline of general purpose programs to accomplish a specific task. If you need the power of Python, or of Lisp for a specific task then write a Python or Lisp program and use it in your shell script. –That simple!
WRT the “million different and inconsitently named command line parameters” That is what people say when they don’t know how to use the CLI. The truth is that you only need to remember 10 – 15 commands, those are the ones that you use all the time, for everything else there are man pages.
All I am saying is give it a chance before you knock it. You will be surprised.
— cludwin
“UNIX is simple and coherent, but it takes a true genius, (or a programmer at any rate) to understand and appreciate its simplicity.”
— Dennis Ritchie.
Or what I mean is, people should have the option to CHOOSE which they want to use. I am not inherently opposed to the CLI and use it often (even in Windows), but I don’t like being FORCED to use it when I don’t want to. Yes, I know that back in the old days, people used to solder their computers together and type on octal keyboards, but we don’t live in the stone age anymore
Often times, tasks (such as ping, tracert, etc) are easier in a CLI, but they are certainly not INTUITIVE. What I mean is, with a GUI, I can usually just look at the interface and be able to tell what I’m supposed to do, where as a CLI if I am approaching a tool/utility for the first time, I’ve got no idea how to use it. This is not necessarily a bad thing, unless I just want to get the f**king thing working. In that case, GUI is king. So, let me at least get it working with the GUI, and then I’ll go back and learn the implementation when I have the time/patience/willingness to deal with it.
“As a poster before me said: why not combine them?
Let’s analyze that CLI means command line interface, GUI means graphical user interface, what about a command driven graphical user interface (AFAIK THE is somethimg like that)?
At least the biggest disadvantages of both GUIs (flexibility, reusability) and CLIs(memorization, data representation) is by design, not per se.”
You have just described the Bloomberg terminal interface. For those who don’t know, Bloomberg is a service that gives you all sorts of data in the world of finance. It was founded by the current mayor of NYC, Michael Bloomberg. At the top of your terminal (spread over 2 – 4 LCD screens), there is a command line. Just below the command line is the GUI, which is mostly used for output, but can be clicked on if you prefer. You navigate the system through different menues and commands. Depending upon your specialty, you only have to know a few key commands. If you’re good with the commands, you can navigate the system very quickly and get a lot done. If you’re a novice, you can drill through the menues on the GUI portion, but it will take you longer.
Here is what I have learned over the years….
The most advanced computer people almost always prefer the CLI for many taks.
Those who are not advanced in their computer “skills”(for lack of a better word) are pretty much always going to stick with the GUI.
I have found this true in people who admin Novell, UNIX, and especially Windows these days.
It just seems to be a fact that the real advanced admins use the CLI instead of the GUI… I find it especially facinating to see genuis Windows admins do their magic on the command line compared to the way their peers who use the GUI perform the same tasks.
It all comes down to sheer amounts of knowledge you have packed into your brain… if you know a huge amount about the operating system then the command line is natural, if you dont then the GUI helps because you don’t have to know nearly as much due to the fact it will prompt you and you can stuble through most admin tasks.
I think modern OS’s need BOTH CLI and GUI admin tools to simply support the 2 types of admins… the highly advanced admins and the normal types…both can be the most productive they can be that way.
AND YES, Microsoft has a goal to make their whole OS admin easily via the CLI just like UNIX. They have a huge number of people working on this right now. They have a desire to take this unique argument in favor of NIX away from the NIX community by being able to also say their system is easy to remote admin via CLI. I was at a major conference in the past year, and attended a late night break out session with Microsoft people discussing this very thing.
>WRT the “million different and inconsitently named
>command line parameters” That is what people say when
>they don’t know how to use the CLI. The truth is that you
>only need to remember 10 – 15 commands, those are the
>ones that you use all the time, for everything else there
>are man pages.
There are a few commands where I have memorized some command line options. From the top of my head: ps,ls,df,du,dd,cd,tar,mount,umount,cdrecord,mkisofs,touc,ssh,scp,less, wget
But I would like to use the CLI much more often. And in many cases the only thing that prevents me from doing so is the tedious process of looking up the relevant command line parameters in the man pages between thousands of seldom-used options. Parameter help like in modern IDEs would make this much easier.
>All I am saying is give it a chance before you knock it.
>You will be surprised.
I have been using Linux since 1995, and ms-dos before that, so I *know* how to use a CLI. But the big problem of a CLI is that the available options are not preseted to the user like in a gui. Take for example cdrecord vs. a GUI cd burn program like k3b. cdrecord is much more reliable, but to find out how to enable some special option like burn proof you have to read a huge man page or type cdrecord –help | less and read three pages of mostly useless options. This might be acceptable if you write a script that will be executed thousands of times, but for one time usage that is just not acceptable!
I really hope that somebody is working on something like this. I love the concept of the CLI, but I should not have to remember a million different and inconsitently named command line parameters and use an antiquated language like bash…
Language designers can come up with features targeting the common user, it is just that new idioms must be added in the language like implementing a certain task in different terms. For example, copy and paste can modified from binary to a unary involving two separate steps.
You just described emacs.
Really these are just tools. All their components can be good and bad, and they can be used for good or ill.
Between 82 and 86 I used CLI interfaces. In 87 I found the amiga. That was the only GUI I used until 93 – my amiga 500 died
It was ressurected though 2 years ago, Yay for ebay. I liked it so much I got a 2000 and a 1000 to go with it.
In 95 I got a 386 with win 3.1. Since then I’ve used dozens of GUI – CDE of Sun and AIX, KDE, Gnome, Blackbox, the list is long. What amazes me is that after decades of CLI use, including VAX-VMS and older Unix, I am _still_ finding nifty things to do with CLI…even coupling CLI and GUI together to solve problems.
Of course, aesthetics. […] I think the Luna widgets are the coolest thing since GEM
I think you’ve never seen or used NeXT/OPENSTEP, or it’s reincarnation in form of OS X and GNUstep…
“Mutt, vi, bash – they all beat their gui counterparts hands down.”
what the heck is bash’s GUI counterpart?
“what the heck is bash’s GUI counterpart?
”
Explorer. They’re both big, slow, and prone to crashing
i simply required to type:
ws
123
dbase
…then i got GUI (even in text mode and usually no mouse support) to get my work done..
‘CLI better than GUI’ simply an excuse by linux people because their GUI (gnome/kde/gnustep) are sucks!! no Complete, not transparent, hard to install, not consistent, no usefull Apps, primitife, not inovative just copy someone else hard work …
“not inovative just copy someone else hard work …”
You’re an idiot.
Well i use Windows as well as Unix. And in Unix i use CLI instead of GUI. Can any one copy a file – paste it at 10 different locations and then delete in one stroke in Windows. If So plz tell me how to do it. Well it can do it most effeciently under unix.
Good lord knows I do that everyday.
The CLIM ( http://www.cliki.net/CLIM ) user interface management system has provided a means for integrated usage of a command shell and a graphical shell for over a decade now. Because it’s written in Lisp, though, it’s been subject to political problems for years.
I agreed with mh. ‘screen’ is my BEST friend when using CLI or text console terminal. Currently, my desktop (XFree86 + evilwm) only have, 2 virtual desktops, 1 desktop for 4 windows of rxvts and one of it, permanenty runs on ‘screen’. Other virtual desktop runs mozilla in full screen right now (while typing this comment). Previously, before using “screen”; my desktop ussually cluttered with nearly 10 or more rxvts (console terminals) and quite painfully to handle it. Now, everythings are in order and well organized, thanks to “screen”. ‘screen’ also have capabilities to spilt consoles as many as you want, so, you see/monitor all terminals simultaneously.
Other than ‘screen’; this text windowing system (TWIN) also cool and I have used it for long time before I use ‘screen’.
http://linuz.sns.it/~max/twin/
http://sourceforge.net/project/showfiles.php?group_id=4280
the ‘screen’ homepage:
http://www.gnu.org/software/screen/
http://www.math.fu-berlin.de/~guckes/screen/index.php3
I was always a huge fan of Directory Opus back on the Amiga. It was a GUI file manager that allowed a huge degree of customization — you could edit/create your own buttons, which performed CLI commands on files selected via the two-pane GUI – thus giving you the power of the command line (minus a bit of flexibility, as you had to open the config and make a new button to use a different command) with the speed and intuitiveness of a GUI. There’s a similar Linux-based file manager called Gentoo, but it’s a bit weak in comparison.
I always thought this design could be vastly improved by the addition of a command line window to the GUI, though. Type in a one-off command to run it on the fileset selected in one of the panes, or right click a button and have its command dropped into the command window so you could add some extra parameter or something.
There’s no doubt in my mind that command line is still by and far the easiest and best way to troubleshoot, and to get a lot of things done that a GUI simply can’t handle. And I’m sure it’s as much a case for *nix systems as it is for Windows.
For example, I was unable to delete a bad file from a floppy because it crashed Windows Explorer every time I tried to access it. So I went into Command Prompt, typed in DEL a:filename and voila, the file’s deleted without hassle. That’s not to say there’s anything wrong with my XP Professional machine (which, remarkably, has been extremely reliable in the time I’ve used it) but that the cumbersome nature and high overhead of many GUIs make it difficult to get some things done and command line is still extremely useful.
One area advantage a GUI has over a CLI is when the machine is set up to use a language other than the one you understand. Couldn’t tell you the Danish or French for dir or format but I sure have done both in a GUI in said languages.