Talk:Command line interface

From Wikipedia, the free encyclopedia

 This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
??? This article has not yet received a rating on the quality scale.
Top This article has been rated as top-importance on the importance scale

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)
Re: #3: Well most users of CLI are on a Unix-based system. The only major system that is not Unix-based is Windows, very few people use DOS for more than trivial tasks and DOS cannot do much in 2007, it cannot access much of the running system for example. But many people on Windows are using PuTTY, Cygwin and Exceed and will be using a Unix-style shell. —Preceding unsigned comment added by 82.36.234.82 (talk • contribs) 14:39 (UTC), 6 April 2007
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)
kim@empire ~ $ ps -ef | wc -l
59
kim@empire ~ $ ssh they
Last login: Tue Feb  5 17:14:19 2008 from empire.lan
kim@they ~ $ ps -ef | wc -l
100
kim@they ~ $ ssh thex
Last login: Tue Feb  5 17:13:53 2008 from empire.lan
kim@thex ~ $ ps -ef | wc -l
50
kim@thex ~ $ ssh bruning
kim@bruning's password: 
Last login: Tue Feb  5 19:25:56 2008 from empire.lan
Tue 14 Jun 2005:

New 200GB is working fine, but jury rigged. Still gotta get it mounted properly.
Alls well! Maybe I'll move the extended directories to the 200 Gb drive, and instal gentoo over the 80 Gb one.
kim@bruning:~ > ps -ef | wc -l                                          [19:59]
    110
kim@bruning:~ > bc                                                      [19:59]
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
59+100+50+110
319
kim@bruning:~ >                                                         [20:01]

319 processes on 4 different computers. You can keep your GUI, thanks ;-) --Kim Bruning (talk) 18:44, 5 February 2008 (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? —Preceding unsigned comment 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?

Yes, I disagree with "A Command Line Interface or CLI is a method of interacting with an operating system". It should read "operating system *or* program". Examples of other programs with CLIs are the MySQL client and the S+/R statistical package. Alex.g 07:59, 18 May 2007 (UTC)

[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 {{Fact}} 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)

So what's this about kids learning Logo? Seems like a CLI to me? (Ok, so there's also a cute robot ;-) ) --Kim Bruning 12:26, 16 April 2007 (UTC) This is an old holy war folks. Can we just live and let live?

[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)
  • What's more worisome is the total lack of an article on computer interpreted languages. Sigh! Since there is no consensus, and since the nom applied the template sans referencing it to a talk section, am removing the merge tags... nine months is a bit too long to bear. // FrankB 19:35, 7 December 2007 (UTC)

[edit] CLI and Resource Protection

This section seems like (WP:OR) you could say that that those protections are not because of the CLI command interpreter but because the file system drivers are protecting its resources. Access rights are granted read only, hidden, ownership are based on the file system. You can also be denied access though API calls and though GUI interface. I plan on nuking this section if there is no citations. In NTFS you can be denied file listing based on permissions. What I'm saying here is someone wrote this section based largely on experience without considering the underlying aspects of the system. —The preceding unsigned comment was added by Getonyourfeet (talk • contribs) 12:00, 5 April 2007 (UTC).

Concurred--nuke it. It's not about CLI at all. DMacks 16:50, 5 April 2007 (UTC)
  • Disputed. CLInterpreter. The sense of this section WAS to compare resource security as in Unix/Linux/Win32 CLInterpreters(which is implemented deeply, to the driver level) to that in some older ROUTER-type embedded CLInterpreters(which is implemented shallowly, in the CLI itself). Hence they impose resource restrictions in two entirely different ways. The sense of that comparison has been destroyed, the two paragraphs are not related, and the first is now a loopy hyperdetailed mess. Please gently revert back to sensibility. The CLI/CLI world didn't start and end with any particular resource protection method.
Am I to infer that you don't want CLInterpreter merged into this article?
I copyedited those paras for clarity, and added the section name. I decided not to nuke it myself, because I've done a little router configuration, and don't have the manuals in front of me. The original author was anonymous, more's the pity. --Lexein 17:10, 14 April 2007 (UTC)
The current version is fine...I fixed your problems now you want to revert from more concrete version with some evidence to a more abstract version without citations or without some substantiated evidence. Also you want to use OS and router implementations with apples and oranges comparison... one built for productivity, business, and home (MS-DOS) versus the other for protection and security (unknown X). why add more confusion? just use one example from start to end which I did. Not everyone owns this older router you talk about plus it is not notable...CLI implemented router not discussed in router page. People are familiar with "root" mode and "guest" mode... "administrator" mode and "user" mode... not "interface" and "system"... K.I.S.S. Getonyourfeet 18:34, 14 April 2007 (UTC)
  1. I consider the recent section edits vandalism by a user who is unfamiliar with the breadth of the subject matter ("email this user" is disabled on your User page).
  2. I'm happy not to own this or any article. (retracted. Still true, but inappropriate in context. --Lexein 03:57, 15 April 2007 (UTC))
  3. Using correct names of the two modes is certainly important.
  4. You didn't "fix" any of my "problems", you undid my repairs on earlier slush.
  5. You constructed this grade-school grade-F punctuation-free runon sentence: Security of resources is provided by a system, which includes resource ownership, groups, and file permissions are manipulated by utilities such as attrib (MS-DOS and Windows) or chmod and chown (Unix/Linux) although these protections are not exclusive to just CLIs for which are stored in the filesystems metadata or access control lists, and the password-protected user accounts are part of a specific groups who are aided by CLI based utilities that work close with the operating system that encapsulate security complexity for the user such programs like passwd, login, and useradd included in the Shadow Suite are found in many Unix and Linux distributions.
  6. The second paragraph no longer compares and contrasts two inherently different types of resource protection, which was the intended purpose, and it reads as nonsense.
  7. Since your stated aim is to get this section nuked, you're well on the way to making it so.
  8. I won't edit war this section (I never do—look it up), which means I won't touch it until you edit it for proper grammar and punctuation. If that means revert-then-correct, then yes, that's what I mean.
  9. If you nuke the section, you will be deliberately misleading readers into believing there's only one kind of CLI/CLI. --Lexein 01:28, 15 April 2007 (UTC)
I don't give my email for personal reasons... plus spam... plus potential litigation (get canned for posting material showing corporate wrongdoing). I am here, no need for email. Do not put words in my mouth, did I ever say I own this page? Wikipedia is editable by anyone and if you don't like these criticisms and claim it as vandalism then you have problems. You sir are exaggerating the situation and wrongfully so. Also, punctuation and grammar mistakes are expected from everyone. Computers make mistakes and English professors say check your work by multiple readers. You didn't even attempt to fix it. Whining is not gonna fix anything. I admit I make mistakes. I'm human I don't claim to be perfect. If I wanted to nuke it, I would have done it at that time. Since weeks past after making proper corrections to fix material not cited and being satisfied, to this date, I say it is fine. If you want to bring your router comparison make sure you cite your work or else editors like me will delete your material. If you think I'm censoring material, you are wrong. Getonyourfeet 02:14, 15 April 2007 (UTC)
  • I reiterate #8. In this case, I edited for comprehension and readability, leaving to others the citations, only to come back and find it destroyed. I hate edit wars, and so reiterate #8. This is a valid reason for not editing, and is not to be construed as whining. --Lexein 03:57, 15 April 2007 (UTC)

[edit] What's the difference between a command line interpreter and a command line interface

Well the former actually interprets commands, and the latter is an interface. IE. on the one os set I know backwards (RISC OS), OSCLI (the Operating System Command Line Interpreter) could be called from several different locations. Most programs providing command line interfaces (such as BASIC) on RISC OS gave access to OSCLI by way of a leading * escaping the rest of the line. (therefore commands to be handed to oscli are known as "star commands"). If no other command line interface was running, RISC OS would provide a simple "star prompt" which fed commands directly to OSCLI . --Kim Bruning 12:24, 16 April 2007 (UTC)

I totally agree with you. There's a major major difference and the two articles should not be merged into one, although a new user has to read 'Command line interpreter' BEFORE 'Command line interface' in order to understand anything. -- Artagnon 06:20, 19 April 2007 (UTC)
Of course, don't merge. Command interpreter is a special software, specifically intended to get commands, either from user as from a batch file. It is an OS component. In other side, any program may have a CLI, e.g. a video game can have a so named console (see ru:Интерфейс командной строки (Russian)). Also, an IRC server obviously implements a CLI but it is never considered as a command interpreter. Different notions. гык 12:19, 12 June 2007 (UTC)

[edit] Article Name

There's this article called cmd.exe and it leads to a download page due to the nature of it's name/file extension. Is there an actual article for it or is it just a wrongly named link? Songjin 12:38, 8 June 2007 (UTC)

It leads to an article for me. What browser are you using? --Yath 14:20, 8 June 2007 (UTC)
Well I use Mozilla Firefox and it always leads me to a download page for that specific article. I've tried Internet Explorer too (v6) and it still doesn't work. Maybe the article name should be changed? Or unless I'm just simply using outdated browser versions? Songjin 04:31, 17 June 2007 (UTC)
What Firefox? I have 2.0.0.4 and it is fine. It might be a Windows thing—using extensions instead of MIME types to determine what the file is. We might want to move it for compatibility, though. —Dmbrown00 04:39, 17 June 2007 (UTC)
Ok I've just updated firefox to the latest version same problem still. Unless this is a just a browser-related problem, could the article be renamed? Songjin 07:48, 20 June 2007 (UTC)
I tried it in Fx 2.0.0.4 and IE6 on a WinXP system; it works fine. What security program are you using? It might force you to download rather than run "executables." —Dmbrown00 15:39, 21 June 2007 (UTC)

Cmd.exe now redirects to Command Prompt (Windows). --Kim Bruning (talk) 18:48, 5 February 2008 (UTC)