Talk:Command line interface

From Wikipedia, the free encyclopedia

You have new messages (last change).

Contents

[edit] Advantages section

I do not agree with the part about the advantages of CLI's. Consistence is not an advantage of CLI's over GUI. It is an advantage over carefully designed (as said here) CLI's over uncarefully designed GUI's. In my opinion the biggest advantage of a CLI's is that it can become a second language. If I want a calendar in my CLI, I just type calendar instead of moving my mouse to the start button, clicking, looking where the item programs is, moving my mouse there, then find and move to accesoires then find and move to calendar (assuming you have a calendar there).

(By the way, please sign your edits to talk pages.) If you disagree with parts of the article, rewrite them. If you think it's incomplete, feel free to add a section on the disadvantages. --grendel|khan 16:13, 2004 Jun 4 (UTC)

[edit] Multitasking

Omegatron, I'm sorry but I have to disagree with your addition on September 2:

* Command line interfaces are not efficient for multitasking; they do not offer the same ability to view multiple program outputs or content simultaneously.

I commonly have literally hundreds of tasks going simultaneously in a CLI and view the output of any or several of them at once. While you may not be comfortable doing it, that does not mean it cannot be done. If it were not for the word "same" I'd have to say this sentence is completely false in my experience. No, it is not the "same" in that the output is not surrounded with GUI chrome and icons, but functionally I think you can do all the same tasks (except those that are inherently graphic, such as drawing an image): view parts of several documents at once, choose text from one document and insert it in another. Can you help me understand what you were driving at here? --Chauncey27 16:57, 28 October 2005 (UTC)

  1. This is an article about CLIs. It's not CLIs vs GUIs deathmatch.
  2. If you're going to compare these two very broad paradigms, you'll have to compare all different implementations at once. You can't talk about the best CLI vs the worst GUI. Compare apples with apples.
  3. The current version is heavily biased in favor of (Unix-based) CLIs due to the type of people who contribute to the Wikipedia; a case of systemic bias which needs to be removed and balanced out by NPOV comparisons.
  4. CLIs aren't efficient at multi-tasking, in general. Just because you can do something doesn't mean you're doing it efficiently. — Omegatron 18:28, 28 October 2005 (UTC)
And just be cause you can do something doesn't mean you aren't doing it efficiently. Do you have anything to suggest that multitasking in CLIs is, in general, less efficient than in GUIs? I find that (yes, unix specific) running multiple tasks through GNU Screen (either locally or through ssh) to be vastly superior to anything I have seen in any GUI. The user interfaces to programs running on the localhost are identical to those running on remote hosts. Furthermore, both interactive and non-interactive cli applications typically deal with text data. The ways in which separate programs can interact with eachother is limited only by the imagination and ability of the user. It's all just text processing.
There are areas where CLI is definately at a disadvantage to GUI. When it comes to specifically graphical applications like modeling, image manipulation, splicing video and audio together, etc. then GUI is probably the way to go in the vast majority of cases. However, multitasking under a GUI (at least any GUIs I have ever seen) is painful for anyone who has a decent amount of experience using the command line.

--207.81.225.190 17:36, 3 September 2006 (UTC)

[edit] Strange acronym

"At least one person also calls it a CLUE, for Command Line User Environment."

That sentence is a bit odd, anybody want to explain it? Why At least one person? --Edward 13:16, 4 Jun 2004 (UTC)

The Linux Documentation Project's Introduction to Linux - A Hands on Guide uses the acronym CLUE in the opening section. I'm pretty sure there have been others as well. --grendel|khan 16:13, 2004 Jun 4 (UTC)
Yes "at least one person calls it..." just looks weird - I'll change it to "It is occasionally called..." I think. --IMSoP 13:12, 20 Jun 2004 (UTC)

[edit] MSH

Command Shell monad won't be ready for inclusion in Longhorn, guys...

[edit] Low-level example

I'd like to begin an open discussion with the person who added the following:

"a user writing a letter or drawing a picture should not need to learn about character encodings or file permissions or kernel modules first."

I just spent most of two days fixing a document written by a person who didn't understand character encoding, therefore they were mystified and highly perplexed when it suddenly occurred to them to put their brilliant work on the web, only to find it looks like excrement on everyone else's computer. Their GUI corrupted their document in ways that they couldn't see. Why is it wrong to expect someone who uses a machine all day to learn how to work it? Would you sniff at the suggestion that a pilot should be expected to understand aerodynamics and balance? Arguing that the author of a document shouldn't have to worry about who else sees it is like arguing that you shouldn't have to be bothered to stick your sexy love letter in an envelope before you drop it in the public mailbox. (Besides, some GUIs can handle permissions, it just takes a ridiculous amount of clicking around to accomplish such a simple task.) And finally your remark about kernel modules, while completely valid, seems aimed at one particular operating system that also happens to feature a CLI along with its kernel modules. They have no direct relationship with each other. I don't want to delete your comment outright, because that isn't nice and you have a valid point. I am asking if you would reframe it somewhat. (However, while I was typing this, apparently someone else reverted your change.) As an aside, if you are going to argue in favor of ignorance, an encyclopedia is not the best place to find supporters, and if you favor pictures over words, why are you typing your updates? Do you want me to sign my comment with my IP address? Or if I make up a name will that make you feel better that you know who you're talking to? Or can we just evaluate ideas on their merit without attribution?

  1. It's an example; lots of operating systems have kernel modules (or similar constructs).
  2. The article will have a strong systemic bias in favor of CLIs, because of the type of people who contribute to the wiki. The article should represent advantages and disadvantages as neutrally as possible. When it depends on opinion, the opinions should be those of the general computer-using population.
  3. Yeah, it's nicer if you have a user name to talk to. If you have a static IP, though, it's no big deal. Either way, please sign your talk page comments with four tildes so we can keep track of who is saying what. — Omegatron 18:24, 6 October 2005 (UTC)
I'm not too sure if this claim (Omegatron's) is true. Dos, the most famous of all CLIs, had none of the things that you mentioned. Take the most common of the OSs that doesnt hide it's CLI : Linux ( from the text you added it almost sounds like a anti-Linux troll post ) this rarely needs attention in the areas you mentioned, if ever, when creating/editing documents/files. --2mcmGespräch 04:50, 7 October 2005 (UTC)
>It's an example; lots of operating systems have kernel modules (or similar constructs).
But that has nothing to do with CLIs one way or the other, does it? If so please clarify. --129.219.55.204 15:06, 7 October 2005 (UTC)
Of course. It's a response to:
  • "GUI advocates claim the support of usability researchers, arguing that among other things the GUI gives the users symbols with which they can interact more intuitively, and that users should not be expected to know how things work. However, this layer of abstraction can also hinder usability. Those whose profession includes providing technical support to such users often observe that the users' frustrations and lost productivity are directly caused by their unwillingness or inability to understand how their chosen tool works."
If you can think of a less OS-specific example, please contribute it. — Omegatron 18:44, 20 October 2005 (UTC)
Why should a person not have to know how their machine works? This is in my view an stupid question. The better question is why should people have to operate at a low level when they can operate at a high level. Does a pilot in an F16 have to know how the circuits of his plane work. NO. Do I have to know how quantum mechanics works to use a computer that is based on solid state physics. No. The beauty of a computer as compared to all possible other things is that it is possible to simulate a higher functionality and more powerful computer within a lower functionality computer. This means I can make my computer look more high level than it really is. For instance if I have a computer that only has the ability to do addition, subtraction, multiplication, division and a few logic operations, I can use this computer to simulate a virtual machine which has extensive libraries, vectors, hashes, binary trees, statistical libraries, Mathematica, regular expressions, objects etc. My virtual machine is a much better machine that the original. Once I have built my virtual machine I never have to deal with the original machine. I can just run everything as if it was in my virtual machine. That is why computers are amazing. I can make a crappy machine look as if it is much more powerful. This is essentially what compilers, virtual machines and operating systems are supposed to do. The whole enterprise of computing is devoted to eliminating the original machine. In many cases the original machine still manages to leak out of our abstractions but this is always because we desire more performance and the higher you go the less speed you have. So we make various comprises between speed and higher level functionality. Unix is a very weird OS than doesn't try to eliminate the original machine at all but instead just tries to provide sets of optional powertools that make the original machine easier to deal with. This is why Unix sucks because it is the leakiest of leaky abstractions. --70.27.25.227
Your analysis rests on the unstated assumption that the command line is "more primitive" and represents "lower functionality". However, that view is not universally shared and represents a particular bias ("POV" in wikipedia-speak). Anyway, discussions in here should focus on what goes into the article, not what is true or false. So did you have some opinion on the article's content? Do you think that the opinion that CLIs represent lesser functionality is underrepresented in the article?
If so, you should feel free to make changes. Hopefully, what you put in the article will be a little more carefully thought out than the above comment. --Yath 17:56, 20 October 2005 (UTC)
:This is why Unix sucks'"'
Most flavors of Unix have (one or more) GUIs, and both Windows and Mac have command lines. So we are not comparing operating systems here, we are comparing ways of controlling them. --Chauncey27 18:26, 20 October 2005 (UTC)

This isn't "CLIs versus GUIs", either. There are more than two types of interfaces, and each type has wildly different implementations. (DOS vs bash, Microsoft Bob vs fluxbox.) Try not to lose sight that the article is about command-line interfaces.

I agree with most of what anon 70.27.25.227 said, but only some of it belongs in this article. — Omegatron 19:20, 20 October 2005 (UTC)

[edit] "I hate the command-line"

Well, obviously, I don't. However, I have removed the link by that name, becasue I don't think its encyclopedic in nature. I also don't agree with the subject of it ("subject of it" = "I hate the command line") , but that wasn't the reason I removed it. I removed it becasue I don't think it was relavant to this article, it gave no important information about CLIs. —The preceding unsigned comment was added by Nick Warren (talk • contribs) 27 October 2005.

I had to remove it again, because someone put it back. It is one sided and it just doesn't need to be linked to in a Wikipedia article. Sorry. Now please, don't put it back. :)

[edit] NPOV

"Those technologists wish the world could share their delight in the sense of power one obtains from controlling the computer with one's ten fleet fingers -- rather than with just two or three mouse buttons, slowed by the time-cost of hauling the mouse-plastic back and forth and up and down over the mouse pad."

Surely there is a more NPOV way of saying this. --Maru (talk) Contribs 23:03, 29 November 2005 (UTC)

[edit] CLI as a way to interact with programs, not computers

I think the current article explains CLI as an historic perspective, but fails to explain how command line interfaces are being used today.

Today, CLI is considered a way to interact with computer software, not with the computer itself. So, for most programs, it's an advantage to have a CLI, so the job the software do can be automated by scripting.

So, the idea I want to add to the article (but I don't know how) is to discuss CLI not just as the previous incarnation of the GUI, but also as an advanced feature for some software, like: backup software, image manipulation tools, diff tools, and even software development tools. --FabioBatista 21:44, 19 March 2006 (UTC)

I wonder if the claim that CLIs "evolved toward GUIs" can be supported. A windowed environment such as Borland's Turbo Vision can't be viewed as an evolutionary step because it's a GUI that uses a character display, and not a CLI. --Yath 18:34, 23 March 2006 (UTC)


[edit] CLI vs GUI section

A section was added today on CLI vs GUI that presented a debate over whether command lines should still be used... it only presented criticisms of CLIs though... still, why was it removed? It seems that instead someone should add reasons FOR the command line, to restore the NPOV. I do not agree that the section "not worth salvaging", as there shoudl be some kind of mention of the pros and cons of CLI vs GUI. Who decides these things? —The preceding unsigned comment was added by 199.172.169.7 (talk • contribs).

I'll restore it and try to reword a bit to provoke less. --TuukkaH 21:44, 29 August 2006 (UTC)
Editors decide these things. I removed it because it reads like a personal essay and can be boiled down to "Some people prefer GUIs because of their shallower learning curve." But if you want to try to salvage it, fine. --Yath 22:51, 29 August 2006 (UTC)
My reason for restoring these arguments is that they are something you inevitably hear today. For example, the university course I took on human-computer interaction presented these. However, they did not present the pro-CLI side to the same extent. I've now added some arguments from that side. Obviously, the section still needs references to reliable secondary sources. --TuukkaH 10:41, 30 August 2006 (UTC)
I replaced this section with a summary. I was 'liberal' with my edits like we are encouraged to do here. If I was too 'liberal', people can bring back text, but I'd like to make a plea for restraint. This isn't the place to settle the argument. —The preceding unsigned comment was added by 47.248.0.45 (talk • contribs).
Way too liberal IMO (and you forgot to even add an edit summary so we could know what you were doing). Especially disagreeable to me was removal of the common examples from the lead section. I have no objection to removal of much of the rox/sux debate as long as some objective pros and cons are kept. DMacks 18:50, 4 January 2007 (UTC)

The section is way out of control. A lot of the arguments in the section aren't even true. There are CLIs that actually behave a lot like GUIs, such as cursors-based CLIs, and there are a lot of CLIs that provide you the list of available commands quite often, so there isn't much to remember. Which arguments did you wish to keep to help people understand the differences is a nice concise way?


Didn't we kill this section a long time ago? Why has it come back? — Omegatron 20:13, 16 January 2007 (UTC)

As a user new to this page, I feel the entire CLI vs GUI section should be removed for good as there is almost nothing in the entire section that does not violate NPOV.----calavera 22:57, 29 January 2007 (UTC)
I went ahead and blew most of it away... 99% of it was straight non NPOV crap, and I think the rest should either be moved into another existing or new section, or completely removed as well.----calavera 23:11, 29 January 2007 (UTC)


I find my CLI programs to be smaller than my GUI programs that do the same job, but the GUI will teach the user how to use it. I write CLI applications if I’m the user, or if I think it’s going to become a demon, cron job, or fully automated.

[edit] CLI versus command prompt

There was a prompt from the main page indicating that someone was considering merging this page with command prompt. I didn't see any discussion here, so I've started some.

From my experience these are not the same thing. A command prompt is something that you would expect to see for an OS such as UNIX or MS-DOS. A CLI, among other uses I suppose, is something you would expect to see on an embedded system. As someone has already suggested, it does not give you access to the computer (or the OS), but rather the software running on the computer. It may well be that anembedded system is running Linux, but the CLI likely won't give you access to the OS directly. A command prompt likely would.

I'm not sure what you are trying to say, but it doesn't sound right. A CLI is a particular method by which a program interacts with a person. A command prompt is an on-screen display that indicates to the user that a program using a CLI is ready for input. As far as the definition of those two terms goes, it is unimportant whether the particular program is an operating system shell (such as csh or COMMAND.COM) or an advanced CAD application that supplies a CLI in addition to its GUI. It's also unimportant whether the computer in question is embedded or not. --Yath 13:21, 27 September 2006 (UTC)

My point was more that in common usage since I don't hear people refer to UNIX as a CLI other then to stop and consider that technically it is one and command prompt is certainly not a term that comes up that often in embedded systems. Perhaps it isn't the most compelling part of my argument.

Really the command prompt is a small aspect of a CLI and not one I see used as the definite name of the whole system. I don't know what the original intention of merging the two articles was. I guess having talked it through, if they rolled command prompt into CLI, that would work. If they rolled CLI into command prompt, that would be completely broken. CLI is an important term and needs to continue to exist.

I agree completely. The material in command prompt should be a section in this article. On the other hand, some of the recent additions here look like original research:
It may be possible for two different CLIs to agree on either syntax or semantics, but it only when they agree on both that they can be considered sufficiently similar to allow users to use both systems without needing to relearn anything as well as enable re-use of scripts.
I'm not sure whether that is encyclopedic material. --Yath 13:56, 27 September 2006 (UTC)

We'll I don't do research, so it can't be ;-). It is very common when looking at machine to machine interfaces (and I view CLI as an odd hybrid between an HMI and an MMI) to divide the problem into syntax and semantics. I can try and find some supporting references, particularly for CLIs. Plus, it's really just giving a name to something most people intuitively know.

[edit] Example CLIs

In general I notice a strong bias in these discussions towards computer systems CLIs such as windows and UNIX. These are popular so should be prominent on the page, but I have on a number of occasions made changes to tweak the article to better suit the broader definition of CLI and these changes are often reverted. By broader definition I mean lesser known CLIs that often appear on embedded devices, but I am sure there are other examples. The latest edit being the 1.5 paragraphs in introduction section talking about specific windows/UNIX CLIs which I moved to a separate section. I'm not saying I'm right and the people who revert edits are wrong, but rather trying to find the best way to ensure the entry is accurate and complete. Would an example CLI section just after the introduction material have been better then having it at the end?

[edit] Editor is removing material in CLI vs GUI which perfectly accurate and verifiable

"GUIs are more intuitive for non techies" This is verifiable and accurate. Children in kinderguarden use GUI programs and in elementary school without reading the manual they always push and click buttons. Teacher explain to them how to use them. All the magic is all done by them without alot of reading. The general public pushes ATM buttons without even reading the entire the whole manual of the ATM. Futhermore, real men don't read instructions... LAWL. New manuals don't come with blocks of text these days.

pardon my butting in, but I just added an external link to an essay, by an educator who observes that (adult) non-techie students seemed to find a CLI far more intuitive than GUIs. An interesting read, very relevant to this discussion. -mykle-
no pardon is necessary. Your link is very relevant here and is a perfect example of why the CLI vs GUI section needs to be closely monitored for people trying to use it as a forum for their own personal opinions. Without links to articles such as the one you provided, people just keep trying to state that their personal opinions are accurate and verifiable and should therefore be in that section.----calavera 20:13, 12 March 2007 (UTC)

"GUIs have better eyecandy and are visually appealing than their CLI equivalents. Such examples include skinable GUI MPlayer vs CLI textual updated MPlayer; or Beryl's 3D graphical window manager vs textbased ratpoison window manager."

Come on man. This is also verifiable and accurate. The language may not be perfect however it does represent the viewpoint of those who use both programs. GUIs they believe are better. There are more Windows users than DOS >3.x users. There are more Windows users than BASH users. More MS Office users than WordPerfect 5.x DOS users.

"GUI is more for people that remember things visually. Where CLI is more for people that remember things like its a language." This is accurate and verifiable. We have visual learners and we have kinesthesic learners. Both are conditioned to work with environment and habits. Biologist use GUI programs not CLI programs when it comes to animals. Have you seen a monkey work CLI? NO!

Material on Wikipedia doesn't need to be factual just verifiable and accurate. Wikipedia contains strange articles not in the domain of reality. Pseudoscience, UFOs, Chupacabras, bigfoot are articles in Wikipedia. I DARE YOU to delete those articles. Material on Wikipedia doesn't have to be factual... just be accurate and verifiable. The flat earth theory is an article in Wikipedia some people *still* believe the world is flat. Santa is a wikipedia article. I dare you to delete Santa's article. You make kids cry.

Maybe you should be more kind and tag those articles with [citation needed] or give the editors a chance to fix their works. Or bring attention to this talk page. —The preceding unsigned comment was added by Getonyourfeet (talk • contribs) 11:29, 18 February 2007 (UTC1)

I don't have time at the moment for a complete response to your position, but I want to point out this section from the Verifiable article:
"Verifiable" in this context means that any reader should be able to check that material added to Wikipedia has already been published by a reliable source. Editors should provide a reliable source for quotations and for any material that is challenged or is likely to be challenged, or it may be removed.
If you feel that these statements are verifiable in this sense, then go ahead and find reliable sources, cite them, and put these statements back into the section, otherwise they will always be in danger of removal. --calavera 19:04, 20 February 2007 (UTC)
I also wonder why you feel the need to create an entirely new section that singles out and attacks my edits considering there is already a section on this talk page dedicated to the CLI vs GUI section debate. The reasoning behind my edits is already stated over and over again by others in this section, and it would be preferable if you would stick to debating in that section rather than attacking me... --calavera 20:50, 20 February 2007 (UTC)

[edit] Should Command line interpreter be merged into this article?

Does anyone have any thoughts on merging the Command line interpreter into the Command line interface article? Both are very closely related, and both are expansions for the acronym CLI. Reading WP:MM, the quote in the Merging section that jumps out at me is: "There are two or more pages on related subjects that have a large overlap. Wikipedia is not a dictionary; there does not need to be a separate entry for every concept in the universe. For example, "Flammable" and "Non-flammable" can both be explained in an article on Flammability"' Add your thoughts and opinions below. Thomas Dzubin Talk 15:35, 28 February 2007 (UTC)

I too have been recently wondering why Command line interpreter and Command line interface are two separate articles as I was going to contribute a bulleted list the history of famous CLIs. We have command interpreters which have features outside the domain of the program. Then we have the command interface which I feel is just the conformity of communication flag styles or how the user communicates to the program. Like DOS programs use /? for help and GNU programs use --help or -h for help. Definitely I feel the editors should be more clear or else we just have to merge them. The Command line interface article covers the style of which strings needed to transfer data from one program to another and covers syntax and lower level material. Command line interpreter article goes over features overview the interpreter engines but does not cover the lower level material or syntax found in Command line interface which it should. Also there is confusion between what it means to be a programming language interpreter like you would find in Python and what it means to be a command OS interpreter. The distinction is clear and they shouldn't be mixed up. I believe that Command line interpreter and Command line interface are used interchangeably by some. See if you look at the piping and redirection... that is a feature belongs to the command interpreter section not command line interface section. It is not a feature of the compiled application but a feature of command interpreters.Getonyourfeet 21:33, 28 February 2007 (UTC)
Retrieved from "http://en.wikipedia.org../../../c/o/m/Talk%7ECommand_line_interface_55d5.html"