Talk:Command-line interface

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).—Preceding unsigned comment added by 130.89.198.144 (talk • contribs) 16:36, 29 May 2003

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

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)

I'm not going to agree or disagree with this on multitasking, but I'll disagree with your suggestion that CLIs aren't suited to things relating to graphics. "Graphics" and "graphical user interfaces" aren't one and the same - graphics are essential for humans and GUIs are not. To use a crappy but accessible example, the website at http://uni.xkcd.com is command-line, but has graphics, but doesn't have much GUI (except for the mouseover text). To use a better example, Matlab and Mathematica. To use your own second example, image editing, a command-line is the only easy way to perform the same edit on multiple files, or to specify exact coordinates.

82.0.106.250 (talk) 16:33, 14 January 2014 (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)

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)

MSH

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

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. --2mcm^Gesprä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)

"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. :)

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)

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)

I disagree, the commandline on my Amiga still is exactly as it was in 1985. Likewise the commandline in my Amstrad BASIC interpreter is exactly like it was in 1984. There is no change today at all. — Preceding unsigned comment added by 157.211.135.202 (talk) 16:37, 25 March 2024 (UTC)

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.

Comparing a CLI to a GUI is like comparing a fork to a spoon. Which is better depends on what you're using it for. There are some tasks for which a CLI is better, and some tasks for a GUI is better. This article still needs a CLI vs. GUI, but it needs to give the reader a reasonably good of when to use which. Some of the factors: how much free RAM do you have: a GUI is usually easier to use, but a CLI uses less RAM. If you're writing a small program yourself to get a very narrow task done, then a CLI program takes a lot less time. For my outliner or spreadsheet, I want a GUI, but if all I want to do is to find all the duplicate files and turn them into hard links, a CLI is probably better suited, because it won't take nearly as long to write. Bostoner (talk) 05:27, 16 December 2012 (UTC)

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.

What is this stuff that's still in the main article about "does not give you access to the computer (or the OS), but rather the software running on the computer." How does that differ from any other type of user interface? In fact, one of the main uses of a CLI is system administration. A CLI usually gives you more direct, more low-level access to the OS than a GUI does. Bostoner (talk) 05:17, 16 December 2012 (UTC)

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.

I think Yath explained things well, the command prompt is a piece of a CLI, though it has other uses and should still have it's own page since it is not exclusive to a command line interface. Its history, workings, and uses can be discussed in more detail. The command prompt can also refer to a part of a "console", or even a specific section of a buffer inside a GUI, so relegating it to simply exist in the framework of the CLI is incorrect. I think linking to CLI/#Command Prompt would be terribly confusing to people and ultimately inefficient when creating other pages that refer to the term. I am sandboxing a Command Prompt page that I will link here (as soon as it is created ;) and I'll plan to put it in place once we hash this out between interested parties. If i don't get any opposition in the next few weeks I'll simply make the changes.76.14.212.157 (talk) 18:20, 29 July 2012 (UTC)

the previous comment added by S1id3r0 (talk) 18:24, 29 July 2012 (UTC)

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)

The History needs work

The article seams to be written by a bunch of newcomers to computers. The first command line interfaces were operator interfaces (Used by a professional computer operator on a mainframe computer). With the advent of the mini-computer by DIGITAL Equipment Corp we have small relative inexpensive computers being used bu researchers. Operatoring systems running on early mini computers used command line interfaces. TOPS-10 timesharing operating system was by far the most dominant in the 60's. TOPS-10 CLI was part of the operating system. Withe TOPS-10 A program could be stopped and memory examined and changed and then continued. The DEC-10 TOPS-10 CLI was meant to allow a user at a time sharing terminal the same abilities as being at a standalone computer. With the pseudo TTY device a program could interact with the TOPS-10 is if at a terminal. An operator used such a program to control service tasks such as print spoolers etc. See also:

PDP-10

compuserv use

36-bits forever

Living Computer Museum

--Steamerandy (talk) 21:30, 30 September 2014 (UTC)

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?

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)

I don't think so, as you can use several different types of interpreters from the command line interface. The interpreter is the software that you are utilizing from the interface. -- such as in : cmd.exe explanation from the Microsoft website.

The command shell is a separate software program that provides direct communication between the user and the operating system. The non-graphical command shell user interface provides the environment in which you run character-based applications and utilities. The command shell executes programs and displays their output on the screen by using individual characters similar to the MS-DOS command interpreter Command.com. The Windows XP command shell uses the command interpreter Cmd.exe, which loads applications and directs the flow of information between applications, to translate user input into a form that the operating system understands.

another example of this logic from an interpreter information page here.

The EVMS Command Line Interpreter (EVMS CLI) provides a command-driven user interface for EVMS. The EVMS CLI helps automate volume management tasks and provides an interactive mode in situations where the EVMS GUI is not available.

Because the EVMS CLI is an interpreter, it operates differently than command line utilities for the operating system. The options you specify on the EVMS CLI command line to invoke the EVMS CLI control how the EVMS CLI operates. For example, the command line options tell the CLI where to go for commands to interpret and how often the EVMS CLI must save changes to disk. When invoked, the EVMS CLI prompts for commands.

these examples show that the "command line interface" is an environment 'type' for running (executing) "command line utilities" such as an 'interpreter'. Though you could execute commands in the interpreter without using the ' cli'; which is the reason for the separation. S1id3r0 (talk) 19:46, 7 September 2012 (UTC)

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)

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:Интерфейс командной строки (in 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)

A command-line interface is an interface. It's an alternate to a dialog-box library. CLI's do not necessarily have to be with the user: one configures things like file managers and the Windows registry to use external programs by supplying the command-lines required with each action. The actual command-line is passed through, often without going through a command processor, directly to the application, the output is listened to by the caller.

A command processor processes commands, say from lines in a text file. It does not have to implement a line interface to read the text file. The most common command would be the 'default action', which is when no command is detected. In the OS/2 cmd.exe, the default action is look for an external command of the same name as the first word. I have written dozens of command-processors, none of which feature command lines.

One should note that programs like 4os2, msh, edlin, debug, diskpart, and ed are all 'command processors', which work at the console line. Wendy.krieger (talk) 12:10, 8 March 2012 (UTC)

Cmd.exe

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)

If the real world worked like Windows, your house would burn down every time you got a flyer advertisnig a "Fire Sale". --Wtshymanski (talk) 19:07, 14 December 2011 (UTC)

Character user interface (CUI)

The very first para mentions GUI and TUI (which, as a computer programmer of over 35 years, I've never even heard of), but fails to mention "character user interface" (CUI), which, by example, would be DOS, a non-GUI type of interface, which, typically, looks and acts like a typewriter. Is that what the original author of this article meant by TUI? If so, shouldn't the more common (and correct) acronym of CUI be used, instead of TUI? —Preceding unsigned comment added by Skaizun (talk • contribs) 14:16, 25 July 2008 (UTC)

I think what you mean by "character user interface" (CUI) is usually called "command line interface" (CLI). DOS (the command prompt/command shell) is just one example of a command line interface. You usually type the commands one line at a time, just like using a typewriter. However, this is not true for all DOS apps, like for instance the Norton Commander. The term text user interface (TUI) is often used for more complex text mode user interfaces like this (see also box drawing characters). TUIs are based more on mouse and command key input than on typing commands. I think the pictures in these articles are all very good examples. Do you have any references/sources that use the term "character user interface"? Ghettoblaster (talk) 19:57, 25 July 2008 (UTC)

It should be recalled that it is a CUI, because it involves more than just text.

The "command line", like "chat line interface", derives from the teletype interface. The difference is that in the former, a computer is at the other end, while in the latter, people are at the other end.

What the "command prompt" launches is a terminal running an interactive processor. You can change these individually (by setting COMSPEC in the user environment, or by running a different terminal program (like CONSOLE2). In any case, while a terminal program can run CLI programs, a teletype session can not.

You don't need either a terminal or an interactive processor to run a command line. Neither are present when the 'file | run' dialog is run in Windows: the call goes straight to the OS 'shelexec' interface. You can't run things like internal commands in this prompt.

There are many programs that are interactive processors that present a command line. For example, CMD, COMMAND, DISKPART, EDLIN and DEBUG all do. You can count things like REXXTRY (a script), CENVI and BASIC to this. DISKPART does not require an underlying CMD session. These typically run in a console session, but you can run command lines straight in the GUI (take command v8, PRAXIM). The command line still exists, but PRAXIM does not display a console. It displays output windows (from each command).

A CLI is an interface. A line of text ending with an line-return corresponds to a command for some program to parse. The output is fed through a line stack, back to the user's console, or to some second program. The parser might break up the various bits to pass on to a different program to look at. Piping is handled by the program providing the command line, not the console level.

The CUI derives from the addressable terminal screen. This means that you have a cursor where input will go, and a fully addressable screen. You move the cursor about, and type in text. The difference between the CUI and GUI is that the former is done at the character level, the latter done at pixel level. Dialogs are pop-up windows over the program, eventually leads to multiple windows (eg QBASIC). You could even run a CLI in one of these windows.

You can have CLI programs to multi-task, but the interface itself is not easy to set up. Still, it does not preclude it, since everything that a GUI can do so can a TUI. Reactos has a CTM (character-task-manager), where one can scroll up and down the task list, and kill the process at the active line. A CLI task manager would be TASKLIST and TASKKILL in Windows XP and later.

Wendy.krieger (talk) 08:12, 23 May 2012 (UTC)

Image copyright problem with File:Command prompt on windows vista.png

The image File:Command prompt on windows vista.png is used in this article under a claim of fair use, but it does not have an adequate explanation for why it meets the requirements for such images when used here. In particular, for each page the image is used on, it must have an explanation linking to that page which explains why it needs to be used on that page. Please check

• That there is a non-free use rationale on the image's description page for the use in this article.
• That this article is linked to from the image description page.

This is an automated notice by FairuseBot. For assistance on the image use policy, see Wikipedia:Media copyright questions. --16:46, 3 January 2009 (UTC)

New age CLI

The article seems to be geared only toward old systems or complex programs. There are several new uses for command line input. For example program Launchy indexes and then searches and starts programs and files on your computer by pressing a global shortcut and typing the file name. On web Yub Nub website uses command line in its search box to open websites by typing its abbreviation. Some websites start using command line such as Google Calendar's Quick Add feature. If you ask me command line is future of computers not its past. Anyway, could someone add those examples in the article? (I'm not sure if these really belong in here)

Are you arguing that Graphic Interface (pioneered by the original Macintosh in 1984) will go away someday? If so, you're probably alone, as it's very user-friendly. However, it's certainly true that Graphic Interface is far too oversimplifed for writing software applications (again, applications, not documents--and writing them from scratch, not installing them). I guarantee that there will always be Command Line for that purpose. (Somebody has to write applications.) The Mysterious El Willstro (talk) 19:18, 9 June 2011 (UTC)

Well, Mac brought the GUI to the mass market desktop, but the fine folks at Xerox PARC had been using it for a few years before then. Are there not graphical programming languages? And don't most people writing code do that from inside an edit window in a GUI? Although I admit Microsoft Outlook has now advanced to the stage where it's easier to type Control Shift F instead of burrowing down three levels of ever-changing menus to start the search command. --Wtshymanski (talk) 03:46, 10 June 2011 (UTC)

Any graphical means of applying programming languages would have to be in the late stages of programming that particular application/version. One must understand how a mouse actually works: The mouse/touchpad itself is fitted with source codes that are equivalent to links in each application, and the applications and documents themselves are oriented on a data field of sorts, where information is projected into a mathematical space within the screen as a whole and within each folder. (This is displayed to humans as more or less a literal space via the screen, but as far as the computer is concerned it's a mathematical construct.)

In other words, every Graphic Interface is just a surface with source codes underneath it. An application being programmed completely from scratch does not initially contain source code links with which to interact with a mouse. Therefore, at least the earliest stages of an application's programming would have to be done directly in source code, which means using a Command Line.

However, let's view what I said earlier in context. I was actually rebutting someone who was making it sound like Graphic Interface would go away at some point, which is unlikely given its convenience for typical consumers (as opposed to software engineers). I myself am minimally proficient in a Command Line, having taken Web Design where I sometimes had to make a few features of a project Website that were specialized enough that at least in DreamWeaver 8 those particular features required Code View (DreamWeaver's Command Line mode). Maybe the current version, DreamWeaver 11 (the current subversion being 11.5 apparently), would have fewer such instances, but I don't know that for sure. Anyway, most other people that aren't software engineers (and I'm not one of those either) most likely would lack even my meager proficiency, and would be entirely lost in a Command Line. The Mysterious El Willstro (talk) 05:51, 14 June 2011 (UTC)

"Edit window in a GUI" <> "command line interface". You can quite happily develop software for years without ever needing to drop to a C:\> prompt. --Wtshymanski (talk) 13:34, 14 June 2011 (UTC)

What does the "C:\>" prompt mean, and in what programming language is it used? Also, a Command Line edit window is still a Command Line even if it's surrounded by Graphic Interface elsewhere on the same screen. (Similarly, a Graphic Interface application running within an otherwise Command Line system is still Graphic Interface. Recall that very early versions of Windows were actually DOS, with the Graphic Interface running as a subenvironment application.) The Mysterious El Willstro (talk) 18:10, 14 June 2011 (UTC)

This is undoubtedly the thickest exchange I've had on Wikipedia since consensus decided to keep all the spare parts electronics articles. --Wtshymanski (talk) 02:02, 15 June 2011 (UTC)

Suggest merge

Suggest merge from Command-line interpreter. From a general-purpose encyclopedia point of view, these are redundant topics and could usefully be merged. --Wtshymanski (talk) 19:09, 27 December 2010 (UTC).

Oppose: Other proggies like editors, and databases have command-line interfaces. The CLI replaces dialog boxes (take command console allows you to launch dialogs in place of filling in commands). Command interpreters do not have to give a command prompt, interactive or otherwise. All these need to do is read a batch file, and process the line as commands or as a default action. The default action in say 'cmd.exe' is to look for a file of the same name.

The feature of a command line is that it can be used as a scriptable dialog interface, so to speak. See my other comments. Wendy.krieger (talk) 11:56, 8 March 2012 (UTC)

I am not able get the point of the comment just above me, but this[1] seems not to be a good ultimate solution. IMHO command-line interpreter should be a disambiguation page due to some ambiguity in usage. A program classified as a "command-line interpreter" can provide a command-line interface, but a command-line interpreter usually can also run scripting language files, which has not a less importance, say, for UNIX shells in modern systems, than its direct use by command line interface. On the other hand, command-line interface is a distinct kind of user interface provided not only by programs referred as "command-line interpreters". The page "command-line interpreter" should, first, give a link to "command-line interface", but also list programs to which the description as a "command-line interpreter" is usually applied. Incnis Mrsi (talk) 12:18, 8 March 2012 (UTC)

A command line interface is something between programs or the program and the user. It lies between GUI (which is generally completely with the user), and the API (application program interface), which is always between programs. A good number of programs call helper programs, by configuring command-lines inside the caller.

Likewise, the command-line interface allows for the idea of piping and filters, where output is processed as input by another program. You can pipe to programs which are not command-line, as long as they can be started in the command line, eg dir /s | clip pipes into the clipboard. Buerg's LIST utility does this too.

Compared to a GUI, a command-processor equates to a program, a command equates to a dialog, and an option is a dialog control. The purpose of menus and directories, is to select commands (dialogs). The command help gives a visual idea of commands. This is the level at which programs that provide parallel command-line and dialog interfaces work.

The most common dialects of command processors are COMMAND.COM and the Unix-shells. One can take a Windows NT user and sit him at an OS/2 command line, and the user would be nearly quite at home, since these replicate the DOS interface. On the other hand, the same user would have trouble with the GUI, since PMSHELL and Explorer are different GUI languages. The UNIX shell is likewise different to the DOS shell: most of the general utilities (copy, ls, dir) are external commands the shell is a program shell only.

Before the advant of the CUA, the Graphical User Interfaces were very hard to use. Commands were put in different positions and names: the exit command might be ctrl-K-Q, or /QQ or Alt-F-X, or F10-Y or /QY or F8-Y. These keystrokes varied from program to program. F3 for example, in IBM interface gives exit, while Word-perfect gives help.

Features like permissions to files are implemented in the file-system, or network program. Under Netware, one can have 'traverse permissions', which allows one to cross a directory to a sub-directory, but not stay in it. So one could be at x:\a\b\c or x:\a and use files from there, but not x:\a\b. This does not depend on the command processor.

Likewise, one can name a file in the gui as %%%%%%%%.doc, but the % character has a meaning in dos-like languages. So you really have to delete it by %%%%%%%%%%%%%%%%.doc.

Gui programs can run batches as well, or even macros. For example, the program i_view32.exe, a popular win32 graphic program, allows for running (and saving) batch files, and most word processors and spread sheets support macros. But the script commands do not resemble the GUI commands (except say, in DOS Lotus 1-2-3), so the average user does not write scripts for them.

Wendy.krieger (talk) 10:22, 9 March 2012 (UTC)

I skipped over a large pieces of the reply because the beginning part already contains terminological mistakes and demonstrates poor understanding of some concepts. First, such thing as "configuring command-lines inside the caller" is a bunch of jargon and should not be confused with use a true CLI. These are exec's parameters, so called "command line arguments" for its historical usage. It is possible to pass a file path to argv[1] from a GUI shell. Second, not "the command-line interface allows for the idea of piping and filters", but the UNIX philosophy. Not any command line interface allows pipes on one hand, and pipes are perfectly possible via open—dup2—fork-exec without any CLI (but under a compatible kernel) on the other. One thing is virtually unrelated to another. Third, "menus" are not a kind of CLI. It is a separate UI concept which is possible both in GUI and TUI, but definitely not a part of CLI, because the choice is not a "command". Wendy.krieger confuses "command line interface" with (some kind of) operating system shell, but these are different things – not any CLI is a system shell. Wendy.krieger also confuses several different aspects of UNIX philosophy, such as fork-exec, programs' design for one task by each one, and filters, where any one is not a consequence of another. DOS systems have quite similar command syntax, there are some similarities to "command line arguments", but there are no usable pipes due to lack of multitasking. Windows NT has all things needed for pipes including multitasking and dup2, but these are just impractical due to a different system design. Incnis Mrsi (talk) 13:40, 10 March 2012 (UTC)

A CLI is an interface, not a program. "Configuring command lines inside the caller" is pretty much how 'fork-exec' and shelexec gets the command line to do things. The 'caller' is the programs the command which it has found inside its configuration files. The command line is prepared by the caller and passed down to someone else to process. It's a call pointing to a line of text, exactly as one would do on a teletype.

A command is the level where a prepared line of text or window is sent to be processed by the system (or program). This corresponds to a 'drop' or 'click' by the mouse, or the normal end of a dialog, or pressing 'enter' at the command line. Loading a command is by typing the command name at the prompt, or selecting the program or description from a menu or icon-field. Programs that equate the two do so at this level.

Pipes are a CLI feature. The contrast is to use named temporary files, or clipboards, or system stacks REXX. What makes pipes a CLI feature is that all of the commands that make the pipe lie in one line of text, and the pipe runs in the context of whoever processes that line of text. You can in theory, run a pipe in a GUI, like the open|dup2|fork-exec, but this is still on a single line of text as you might type at a teletype console.

In this case, we see that if a command line is not processed through a command processor, then it makes no use of internal commands and features of the command processor. Using 4NT as COMSPEC for example, does not allow you to put echo %@name[%1] into a shell opject's command line, because command lines in the shell never go to COMSPEC.

Multitasking is not essential for pipes to work. DOS 2 and later quite happily run pipes, since all that is required is that a pipe output is made available for input at the next stage. Temporary files work just as well.

On the other hand, while pipes work quite well in a multi-tasking system (because each pipe exists in the context of the program processing the command text), clipboards don't. You can quite easily munge the user's data by a program that parks data in the system clipboard. Clipboards work because the user is largely single-tasking, although multi-page clipboards do exist.

A number of games, such as Kings Quest 1-3, Police Quest, etc, use the command-line interface. Sierra were quite proud of their game parser (which processed the command line). Typing 'get ring' would be processed by the game to pick up a ring, involving prehaps walking over to the location involved. The cursor moves the character, while anything else was done at the command line. H2G2 ran in a command console in the same manner.

Seeing that i added whole 'Other Command Line Interfaces', and rewrote the intro paragraph, i doubt that i am confusing the CLI for the system interface etc. Wendy.krieger (talk) 08:56, 11 March 2012 (UTC)

Suggest command line interface (no hyphen)

'command line interface' is a compound noun that should not be hyphenated. This also applies to 'command line interpreter' I propose removing the hyphens in this page, and would do it myself right now, but then the title of the article wouldn't match.

Here are the grounds: 1) This is a compound noun, similar to 'graphical user interface', which is not hyphenated. 2) 'command line' is not being used as an adjective to modify the noun 'interface.' The noun *is* command line interface. 3) 'command line interface' is the standard. This form is used by Google and Microsoft, and appears in the Microsoft Manual of Style for Technical Publications. This is my first time proposing any Wikipedia edits, so if I have not managed to follow protocol, please let me know. Nanoterra95 (talk) 21:42, 23 September 2011 (UTC)nanoterra95

I agree with the proposal. - The Aviv (talk) 17:34, 14 December 2011 (UTC)

A hyphen is required in compounds and with adjectives, when the reference is not to the primary noun. In 'graphical user interface' and 'application program interface', all of the adjectives etc refer to 'interface'. In the first, graphical describes UI, in the second, the application owns the PI, but it's the interface that is being referred to.

In 'command-line interface', the command refers to 'line', and the actual process is a line interface. One might note that a command line interface can be used by programs as well as the user, an example being pipes and filters. The configuration of programs like file managers, to use external zip utilities, the windows registry-to-command interface, and so forth, are also 'command lines' which are used to interface between the issuing and recieving program. Some programs can listen to the output too.

One should note that 'command processors' do not equate to 'command lines'. A command processor might well process a batch one line at a time, but this is simply reading and acting on a text file. One does not have to implement features of a command line to read a text file (as opposed to an INI file). Wendy.krieger (talk) 11:51, 8 March 2012 (UTC)

Command-line styles

The Command-line interface is a kind of dialog interface. That is, one might implement dialogs as commands and vice versa. When the command-history is maintained, commands can be retrieved and edited to produce similar but different dialogs.

One should note that command-line interfaces replaced earlier menu-interfaces and file-manager interfaces (like MS-DOS Executive in Windows 2.x). These require no parsing: the user selects the document or program to run, and the program loads it in the default manner. The interface in tandy 1000, and Windows 1.x, 2.x are of this type.

There are editors and data-bases which make use of the command line. For example, PC-DOS E editor uses a command line, where the ms-dos 5 editor has a search and replace dialog, E uses s /search/replace/ style command. E keeps a history of commands, so the searchs and replaces can be recalled over previous calls. You can run an OS/2 command processor in the E command line, the output going straight to the document window.

The teletype console is the parent to the Unix/DOS/OS2/NT command console. With piping (redirection, filters), command editing and history (doskey), and a batch language that matches the UI, these are fairly servicable utilities. It's more the console hacks rather than the UI that makes these quite servicable. Powershell, on the other hand did not take off because its programming language does not match its UI.

Praxim (a windows 3.1 command shell), produces output into different windows, while keeping the DOS command interface. A directory command, like 'dir /w', produces a windows with a directory like DOS, but one can open programs and documents by clicking on its name in the UI. Batches are also supported.

One should note that it is the use of the UI language in batches which makes the batch language easy. Lotus 1-2-3 for DOS used a slash-menu interface both for use and for its macros. It is then a matter of copying these, with ~ for enter, that makes it much easier for novices to program, compared to say, Excel, which uses slash-menus for the UI, but VBA for macros.

Wendy.krieger (talk) 11:29, 8 March 2012 (UTC)

early operating systems (sic)

All of the examples given are mid-range rather than early. An early operating system would be (barring WP:OR) something predating the currently recognizable form, e.g., typical systems from the 1950s through the end of the 1970s, noting that while Unix overlaps that, it is a fairly late event. Also, the overall context is referring to teleprinters (my recollection is that none of the given examples were used predominantly with those devices) TEDickey (talk) 11:26, 26 May 2012 (UTC)

Well, you have programming languages. A lot of the 8-bit machines of the 1970s and 1980s used BASIC as the OS. I mean, basic was as big in the eight-bit stuff as dos was in the 16-bit systems. You have to also note that manual loads of the system, be it a cartrage, tape or deck of cards, means that one could write for a computer without any such operating system. The Atari 2600 had 4 KB of total memory. The Stretch computer (a huge dinosaur decked out in white coats and a side-offering of Halon), sported 77 KB of wire-wound core.

One loaded program and code to run directly into core, with no resident code. Pitfall Harry and Fortran 77 provided their own drivers etc for running dedicated hardware. Some computers did run operating systems, but this was not the norm, apparently. It was more white-coats loading the required tapes.

The teletype was a common interface for time-share systems. The hapless user would sit in a different room, plugging away at code which would be sent and run in an instant, and the output collected next morning from the print room. Also, if you want to, you could sit at one of the key-punches, and punch out a card, either on a single-character punch, or later on a card-punch machine. Such jobs would be submitted to the computer desk, and collected in the next morning. I mean, you often just don't tuch the OS, until you get to things like VMS or whatever. Wendy.krieger (talk) 07:25, 27 May 2012 (UTC)

Operator's consoles (which used command-line interfaces) date at least to the 1960s from my recollection, and from reading they date to the 1950s. Pre-Basic, no high priest needed except for the larger installations TEDickey (talk) 14:52, 27 May 2012 (UTC)

Consoles of this nature were probably running JCL, or VMS or DEC or something. There is in the jargonfile the entry on glass tty's, which as i mentioned earlier are teletypes with a glass printer (screen). These in general did not use basic. basic was more a creature of the eight-bit boxen from the late seventies or eighties, although the interface dates to much older (Dartmouth basic). Wendy.krieger (talk) 07:17, 29 May 2012 (UTC)

Your change of direction of Basic is unclear, since you introduced that (for some unspecified reason). The topic is "Command-line interface", and that covers systems other than Unix or DOS (or some unspecific basic-machine). DEC's command-line systems mostly date from the 1970s, and "VMS or DEC" is rather undescriptive. TEDickey (talk) 21:36, 29 May 2012 (UTC)

BASIC was pretty much the standard OS for 8-bit portables etc in the 1980s. There is no underlying OS: BASIC is the first program to hit the metal. The reason it is replicated in DOS up to version 4, is so that you could run BASIC code (such as might appear in PC magazines), on DOS. GWBASIC still runs under modern O/S for this reason. DOS descends from BASIC in various ways.

Large iron ran a great variety of operating systems, from which Multix and UNIX descends. The typical hardware was things like surplus TTY machines hooked up to the computers. These evolved into glass teletypes, and then terminals. CMD.EXE replicates the glass teletype interface, although it runs in a terminal session.

The sort of stuff that you get on a mainframe teletype could as much be the result of a program running as the OS. Running something like TRPPTUPF might be a program that requests a job on a mainframe. Wendy.krieger (talk) 08:19, 30 May 2012 (UTC)

The section is "early operating systems". Basic is not relevant per your indicated time in the 1980s. By the way, several of your comments might be of interest, but there appear to be no useful WP:RS TEDickey (talk) 10:51, 30 May 2012 (UTC)

Many of the portables and computer-lets, like the commodore 64, and tandy 100, ran on BASIC. It's only when one gets into the fancier MS-DOS compatibles machines that one finds 16-bit processors. Wendy.krieger (talk) 06:55, 31 May 2012 (UTC)

That comment mixes timelines across ten years. TEDickey (talk) 08:51, 1 June 2012 (UTC)

'early' computers. Would be 50s and 60s. None of them sat on a desk. I believe they were almost all batch. Peter Flass (talk) 15:56, 26 October 2012 (UTC)

That sounds like agreement with my comments on the timeframe, but neglects examples that weren't batch (IBM 1620 and minicomputers such as PDP 8 for example). Referring to micros introduced in the mid/later 1970s as "early operating systems" is something that I disagree with TEDickey (talk) 22:53, 26 October 2012 (UTC)

introduced the concept (sic)

The source for that is problematic because it is a primary source. A knowledgeable third-party source for statements of that type is preferable TEDickey (talk) 14:09, 22 September 2013 (UTC)

Good catch - I think there's an ACM article somewhere; I'll try to dig it up. Peter Flass (talk) 14:31, 22 September 2013 (UTC)

Command Lines come from the teletype interface, basically in days of old, one was telexing the computer through ancient teletype machines, and listen to the result. Much of the command-line interface still refers to teletype stuff. Online chat relays still use this interface. Wendy.krieger (talk) 11:07, 23 September 2013 (UTC)

invented terminology

google on "command-based file manager" got 8 hits. One was this Wikipedia topic, 3 were cached copies of one newsgroup comment. Not enough to claim "known as". Conflating "command-line" and "command-based" appears to be WP:OR (at least WP:FRINGE) TEDickey (talk) 21:36, 25 September 2013 (UTC)

distinction between dumb/smart terminals

The tagged edit asserts that the distinction between dumb/smart terminals was whether the terminal was cursor-addressable. The linked topic (which also lacks WP:RS) points to the section mentioning ADM-3A, which was cursor-addressable. As usual, Wikipedia is not a reliable source TEDickey (talk) 20:51, 10 March 2014 (UTC)

I was going to post my own opinion, but here's a nice reference:

Dumb, Smart, and Intelligent Terminals. Peter Flass (talk) 23:08, 10 March 2014 (UTC)

It's a source, but not one that I would call "nice", since a search for credentials of the author finds nothing worth mentioning. Just pulp (grist for Wikipedia, if you like, but zero value for my own use). For a source like that, I'd look to see where the actual information came from, and possibly find some usable sources TEDickey (talk) 23:29, 10 March 2014 (UTC)

A lot more computer stuff seems to be getting published in India these days than in the west. Peter Flass (talk) 02:57, 11 March 2014 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Command-line interface. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20110810070659/http://www.cisco.com:80/en/US/docs/ios/12_0/configfun/configuration/guide/fcui.html to http://www.cisco.com/en/US/docs/ios/12_0/configfun/configuration/guide/fcui.html#wp7687

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 15:40, 28 November 2016 (UTC)

I found the document in question on Cisco's site, and updated the URL (and used {{cite web}}). Guy Harris (talk) 18:59, 28 November 2016 (UTC)

Adventure games

The phrase 'There are a number of pre-mouse games', seems more than a little arrogant + ignorant. Text-based adventure games are a perfectly valid game genre in their own right, not exclusively a stop-gap before monkey island.

Let's change the wikipedia page on 'books' to say that books were something that existed before the invention of moving pictures. It can say that there were a number of books, and give two examples.

...Or we could just fix the idiotic phrase and supplement it with a link to the wikipedia page 'Adventure game' instead. — Preceding unsigned comment added by 92.24.225.48 (talk) 00:38, 5 March 2017 (UTC)

Command-line interpreter is not the same as shell

As far as I know, every program could have a command line interpreter, while only an operating system can have a shell.

However, this article seems to treat command-line interpreters and (command-line) shells as if they were the same thing.

In particular, the introduction says A program which handles the interface is called a command language interpreter or shell (computing) and, in the section Command-line interpreter, "command-line shell" appears as one of the alternative names of command-line interpreter.--Malore (talk) 23:25, 9 July 2018 (UTC)

+1

Any others?

DGerman (talk) 17:13, 21 May 2022 (UTC)

What is the option to output the version information of ls?

What is the option to output the version information of ls? 197.231.179.138 (talk) 09:03, 17 May 2021 (UTC)

To quote the banner at the top of this talk page, "This is not a forum for general discussion of the article's subject." I.e., it's not the place to ask for help on command-line interfaces. Try reading the ls man page on your system for help on the ls command. Guy Harris (talk) 18:38, 17 May 2021 (UTC)

Indecipherable statement in "anatomy of a CLI" section

I can't see how to unpack, how to understand the the 3rd part of the following:

"Command — provided by the user. Commands are usually one of three classes: 1. Internal commands are recognized and processed by the command line interpreter. 2. Included commands run separate executables. 3. External commands run executable files that may be included by other parties."

Call me a general reader. I read pretty much the whole article up to here, then i am stymied. Can part 3 be reworded somehow. Note that "2" seems to define in context "Included commands" as a term in which "included" is an adjective or part of a two-word noun phrase. But "3" uses "included" as an undefined verb and brings up "other parties". I have no idea who those people could be, or how they are entering in to interfere somehow with me, the first party, as i type away at a CLI. Seriously this makes no sense to me, while the article was readable up to here. --Doncram (talk,contribs) 10:03, 14 February 2023 (UTC)

Unless those three phrases - "internal commands", "included commands", and "external commands" - are commonly used, with references to support that, perhaps they should be removed from the text.

As for the classes, there are two distinctions here:

• The first distinction is between those processed entirely by the command-line interpreter, with no additional program or script (or subroutine, as in the Multics shell) not part of the interpreter executed by that interpreter, and those that involve external code.
• The second distinction, between two different subclasses of commands in the second classes above, is between those that are provided by the system on which the interpreter runs and those provided externally.

I'm not sure presenting it as three classes, rather than as two classes, with the second class divided into subclasses, is the right way to present it.

And then there are commands that are, in a sense, processed directly by the command-line interpreter, but that aren't defined by the interpreter; shell functions in the Bourne shell are an example of that - they're like shell scripts, but the commands in them are run by the shell that processes them, rather than being run in a separate instance of the shell, as is the case for most UN*X shells. Some shells might execute scripts in this fashion, rather than in a separate instance of the shell, so It may be that the first distinction above applies to some shells but not others. Guy Harris (talk) 21:40, 14 February 2023 (UTC)

I assume the immediate difficulty here is there's no clue as to what included means. We can improve that to included by the system vendor or somesuch. We can combine the last two categories. We can remove the list of categories altogether. I'd be happy for now with any of these improvements. ~Kvng (talk) 15:12, 19 February 2023 (UTC)

Reversion of my recent edits

Moved from Reversion of my recent edits on the "Command-line interface" article with permission ~Kvng (talk) 19:49, 15 September 2023 (UTC)

Hi Kvng, I see you reverted my recent edits on the "Command-line interface" article. I am happy to work with you to address any flaws in my edits according to WP:BRD.

I guess we can start with the intro. I view my first sentence as an unambiguous improvement in clarity and concision over the previous version's first sentence. (If you disagree that that is an improvement, please tell me why.)

The rest of the introduction is more debatable. I tried to make it simpler, in order to make it more clear to a beginner what a command-line interface is. For example, I removed the mention of command-line interpreters, which are often used to implement command-line interfaces. I did this because, in my opinion, they are tangential to knowing what a command-line interface is, and the purpose of an introduction is to explain what a thing is. A beginner encountering the concept of "command-line interface" for the first time has no need to know about the interpreter until s/he understands that a command-line interface is a thing that takes lines of text as input, and performs some actions as output. In other words, implementation details matter only after one knows what a thing is, and therefore, implementation details belong in a later section than the intro.

I also relegated mention of alternative user interfaces to its own paragraph, to denote the separateness of such interfaces from CLIs. The article is after all not really about them.

Those are my thoughts on the intro. Please let me know what you think. If too much time (say, a few weeks) elapses with no response from you, I will revert back my changes.

Cheers, Likes2wiki (talk) 07:17, 15 September 2023 (UTC)

Here's my revert.

Original

A command-line interface (CLI) is a means of interacting with a computer program by inputting lines of text called command-lines. Command-line interfaces emerged in the mid-1960s, on computer terminals, as a user-friendly alternative to punched cards.

Improved

A command-line interface (CLI) is a means of interacting with a device or computer program with commands from a user or client, and responses from the device or program, in the form of lines of text. Such access was first provided by computer terminals starting in the mid-1960s. This provided an interactive environment not available with punched cards or other input methods.

Your improvement is longer so I'm not sure how credibly you can claim it is more concise. It contains more detail but that doesn't necessarily make it more clear. Additional detail can make things worse. For instance, how does adding device to interacting with a device or computer program make things better? It just seems to raise questions, e.g. What is a device? Client? User? Similar for other input methods further on. ~Kvng (talk) 19:59, 15 September 2023 (UTC)

No, you have the two versions mixed up. My version is the shorter one. Your revert reverts it back to the old, longer, version.

That is, my version's introduction has 727 characters of text in total.

The old version's introduction has 1440 characters of text in total.

(These numbers come from copy-pasting the respective versions into my text editor, VSCode.)

And we are in complete agreement over the phrase a computer program being better than a device or computer program here.

But, again, my edits removed that extraneous material. Your revert adds it back in.

~ Likes2wiki (talk) 21:47, 15 September 2023 (UTC)

You're right. I'm sorry about that. I'd like a little more time to review the rest of it. ~Kvng (talk) 22:53, 15 September 2023 (UTC)

With respect to discussion of command-line interpreter, you've removed a couple WP:BOLDSYN entries with that second paragraph that would help orient readers arriving through Command processor, Command-line processor, Command interpreter, Command line interpreter or Command-line interpreter redirects. The absence of these in the lead is likely to produce unnecessary WP:ASTONISHMENT.

I've restored your lead changes. I've also restored discussion of command-line interpreter. I have then made some further improvements. Let me know what you think.

I'll come back and review your changes to Command-line interface § Comparison to graphical user interfaces in a bit. Thanks for your patience. ~Kvng (talk) 20:53, 16 September 2023 (UTC)

Comments on the new changes:

• The second sentence of the second paragraph lists desktop metaphors as an *alternative* to GUIs, yet they are a *type* of GUI. It also interrupts the rest of the paragraph. After agonizing over where to put this sentence, I decided it might fit better in its own section than in the intro.
• Mentioning interpreters and processors in the first paragraph might scare or confuse casual readers who aren't computer-savvy and who just want to figure out what CLIs are. However, I understand your concern for WP:BOLDSYN. Maybe we could compromise by moving the mention of interpreters and processors to a later paragraph in the introduction.
• The last two sentences of the third paragraph seem too vague; let's remove them and replace them with something more informative.

I incorporated all of the above into this new edit.

Please let me know what you think. And, thanks for taking the time to review.

~ Likes2wiki (talk) 10:00, 18 September 2023 (UTC)