This is the
talk page for discussing improvements to the
Command-line interface article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This ![]() It is of interest to the following WikiProjects: | ||||||||||
|
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
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)
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)
That sentence is a bit odd, anybody want to explain it? Why At least one person? -- Edward 13:16, 4 Jun 2004 (UTC)
Command Shell monad won't be ready for inclusion in Longhorn, guys...
I'd like to begin an open discussion with the person who added the following:
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?
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)
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. :)
Surely there is a more NPOV way of saying this. -- Maru (talk) Contribs 23:03, 29 November 2005 (UTC)
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)
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)
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)
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)
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.
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.
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.
the previous comment added by S1id3r0 ( talk) 18:24, 29 July 2012 (UTC)
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?
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:
-- Steamerandy ( talk) 21:30, 30 September 2014 (UTC)
"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.
"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)
- "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.
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?
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)
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.
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.
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).
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)
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)
Cmd.exe now redirects to Command Prompt (Windows). -- Kim Bruning ( talk) 18:48, 5 February 2008 (UTC)
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)
Wendy.krieger ( talk) 08:12, 23 May 2012 (UTC)
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
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)
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)
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)
'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
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)
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)
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)
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)
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)
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)
Dumb, Smart, and Intelligent Terminals. Peter Flass ( talk) 23:08, 10 March 2014 (UTC)
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:
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{
Sourcecheck}}
).
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— InternetArchiveBot ( Report bug) 15:40, 28 November 2016 (UTC)
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)
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)
What is the option to output the version information of ls? 197.231.179.138 ( talk) 09:03, 17 May 2021 (UTC)
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)
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)
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.
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.
This is the
talk page for discussing improvements to the
Command-line interface article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This ![]() It is of interest to the following WikiProjects: | ||||||||||
|
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
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)
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)
That sentence is a bit odd, anybody want to explain it? Why At least one person? -- Edward 13:16, 4 Jun 2004 (UTC)
Command Shell monad won't be ready for inclusion in Longhorn, guys...
I'd like to begin an open discussion with the person who added the following:
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?
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)
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. :)
Surely there is a more NPOV way of saying this. -- Maru (talk) Contribs 23:03, 29 November 2005 (UTC)
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)
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)
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)
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)
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.
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.
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.
the previous comment added by S1id3r0 ( talk) 18:24, 29 July 2012 (UTC)
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?
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:
-- Steamerandy ( talk) 21:30, 30 September 2014 (UTC)
"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.
"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)
- "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.
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?
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)
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.
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.
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).
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)
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)
Cmd.exe now redirects to Command Prompt (Windows). -- Kim Bruning ( talk) 18:48, 5 February 2008 (UTC)
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)
Wendy.krieger ( talk) 08:12, 23 May 2012 (UTC)
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
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)
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)
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)
'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
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)
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)
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)
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)
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)
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)
Dumb, Smart, and Intelligent Terminals. Peter Flass ( talk) 23:08, 10 March 2014 (UTC)
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:
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{
Sourcecheck}}
).
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— InternetArchiveBot ( Report bug) 15:40, 28 November 2016 (UTC)
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)
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)
What is the option to output the version information of ls? 197.231.179.138 ( talk) 09:03, 17 May 2021 (UTC)
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)
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)
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.
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.