Jump to content

Talk:Shell (computing)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by 47.11.159.166 (talk) at 06:24, 24 November 2016. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
WikiProject iconComputing C‑class High‑importance
WikiProject iconThis article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
CThis article has been rated as C-class on Wikipedia's content assessment scale.
HighThis article has been rated as High-importance on the project's importance scale.

Etymology

What would be really cool would be if someone found out why a Shell is called "shell". Does it have sth. to do with real ocean shells? I found nothing about that in the net yet.--Darkstar

Because it's a "shell" over the operating system. Dysprosia 20:40, 22 Aug 2004 (UTC)
Its a nut annalogy. The shell of a nut is the bit you see. Inside is the kernel which is also the inside of a nut, the bit you eat. thomashauk 19:45, 18 Jun 2007 (UTC)

Neglecting third party shells?

A lot of third party operating systems use shells that are not on this page, for example: "MASH" (minimal bash) used on 5 different operating systems "HASH" a shell project to create a shell that has the same syntax as a social network, (like twitter. it gets its name from the useage of "hash tags" on twitter) although this hasnt been put on any operating systems yet i still think it could deserve a spot on the page xShell: used on different operating systems, dont remember how many. all i know is it started from the syntax of the xcube operating system —Preceding unsigned comment added by 152.26.29.100 (talk) 14:26, 11 March 2011 (UTC)[reply]

Shell vs. Desktop environment

  • I'm slightly confused here: what's the difference between an operating system shell and a desktop environment? Is a shell a certain section of the D.E. that solely deals with management of files or are the words shell and D.E. synonyms? --67.70.21.13 05:17, 6 Mar 2005 (UTC)
    • This could be answered from a specific reading of both articles:
      • Desktop environment: a desktop environment (DE) offers a complete graphical user interface (GUI) solution to operate a computer.
      • Operating system shell: ircThe shell of an operating system is a program that presents an interface to various operating system functions and services.
    • So, while a DE provides a means of a GUI to the user, it need not concern itself with manipulating many aspects of the OS, while a shell is intended for this purpose. To answer your question; a shell and DE overlap, but I wouldn't say they were synonymous or had the same purpose. HTH Dysprosia 05:25, 6 Mar 2005 (UTC)
    • Enlightenment about the "kernel"/"shell" dichotomy can also be found at kernel. Uncle G 12:14, 2005 Mar 6 (UTC)

IMO, desktop environments like GNOME or KDE SC, provide an entire plethora of programs. I think the main problem is the distinction between the GUI of any program, which is composed of GUI widgets and works as part of a Windowing system and special programs like GNOME Panel, GNOME Shell, which can best be termed as "graphical shells". Some people call them UX. User:ScotXWt@lk 11:02, 14 June 2014 (UTC)[reply]

Proposed merge with shell (computing)

I'm the initial author of shell (computing), and I disagree with the proposal by Falerin to merge that article into this one. This article is about operating system shells. Yet the term shell is used more generally in the realm of software applications. Operating system shells are just one of several types of shell. If anything, this article should be merged into that one. — mjb 16:41, 3 August 2005 (UTC)[reply]

  • I agree that the term Shell is in fact used more generally in the realm of software applications. However the current article does not provide much in the way of giving clue to what this usage is, and even in the applications development environment such usage is rare and indeed looose as is suggested. However it is correct to state that more strictly this article is a subset of shell (computing) and in that sense I do not oppose a merge in that direction either. As it is however the later offers little to distinguish itself other then reference that it is used quite loosely in other forms. The operating system shell information if removed only to the point of providing a link would result in an article that is so short that it would neither provide a Wiktionary defintion nor additional description on disambiguation. Expanding the stub as it exists arround the differences without excessive redundancy would seem quite difficult if not impossible. Worse the current Shell disambiguation refers to a redirect and is otherwise confusing. When weighing options merge seemed the most reasonable alernative though I did not do it and redirect because there was more to be discussed. Falerin 06:38, 16 August 2005 (UTC)[reply]
  • I agree with Shell (computing) clearly being more general than the specific genre of operating system shells. The IE Shell article in the Shell article is a good example of that. The general idea behind the naming "shell" is after all basically "an application that wraps another", where a CLI acts as a text-based wrapper for more or less selected OS features, and so on, while another shell may wrap an application not having anything to do with a direct OS communication. I've used an mp3 encoder GUI that acted as a shell for the command-line LAME encoder. Having this article as a section in the Shell article sounds good to me, as a start. Maybe one section for Operating system shells with subsections GUIs and CLIs, and another section for Application shells. That's my 2c on this. -- Jugalator 10:05, 23 September 2005 (UTC)[reply]

Issues regarding scripting languages

I'm having trouble with considering scripting languages as CLI shells. It isn't so much an issue of whether they can be used as shells as whether they're intended to; if they are, we can also add Applescript, HyperTalk, REXX, Ruby, and a few others (Awk? TECO? Emacs?) to the list, and I don't feel that any of them really belong there (although it is possible, if a bit cumbersome, to use Applescript as a command line environment for MacOS Classic, and I presume REXX and Ruby can be used interactively as well). You could also include machine language monitors and debuggers like MacsBug in the definition, in which case you'd be diluting it beyond reasonable usefulness.

As for the issue about generalizing the definition of "shell", I think "shell" is pretty well-established as a special case of "wrapper", not a synonym; it specifically implies an interactive program, with scriptability being secondary to the definition. 141.154.59.77 00:53, 10 May 2006 (UTC)[reply]

Shells etc

A shell is meant to be a wrapper around some underlying system. It is pretty much what is being wrapped.
For example, something like XTREE, Midnight commander, FC/2 etc are wrappers around file management in different systems, and are often called shells. However, one would not set something like COMSPEC=C:\XTREE\XTG.COM, because XTree requires an underlying command processor to do the work.
Something like diskpart.exe or ftp.exe is an interactive program, that supports scripts, but is hardly a shell. These programs are not intended to launch programs, and are largely intended to do something that a stand-alone gui might do.
Scripting language, especially scripting glue (rexx, vba), provide a common scripting across different applications, and usually start external programs or commands as well. Yet such glue would hardly be a shell program.
On the other hand, the tandy 100 computer used MS-BASIC 3.21 as the shell. That is, it is the direct interface to the hardware. One might consider that BASIC, in its earliest incarnations was really both operating system and shell. Command.com is derived from basic.
Modern shells restart themselves by way of being their own parent. One sees this when command.com in DOS, or Windows explorer or OS/2 pmshell is stopped: the operating system restarts them. Viruses also restart, but this is usually because of parallel processes that restart each other. On the other hand, Windows 3.1 shells exit both themselves and the underlying APIs.

Wendy.krieger 11:06, 23 August 2007 (UTC)[reply]

Merging Desktop shell replacement into this page

The following is material from that page's talk page, originally suggesting a rename for that page, and later suggesting that it be merged into this page. Continue discussion here. Guy Harris 18:05, 7 September 2007 (UTC)[reply]

Since this is a Windows-specific phenomenon, instead of calling this articke "Desktop shell replacement," perhaps a more suitable title would be "Explorer shell replacement?" (Or "Explorer.exe shell replacement") —Tokek 11:55, 18 January 2006 (UTC)[reply]

How about Alternative shell - Stephanie Daugherty (Triona) - Talk - Comment - 21:14, 14 September 2006 (UTC)[reply]
Alternative shell doesn't address the issue. Alternative shell could refer to a unix command line shell, or any other user interface shell replacement. This article is specifically about replacing the windows shell, the part of the windows interface known as "explorer". -- JoshuaRodman (not logged in) 64.142.12.203 11:53, 6 February 2007 (UTC)[reply]
What about something like "Windows desktop environments", "Windows graphical shells", or "Windows desktop shells"? The article could mention the default shell provided with Windows and link to Windows Shell, then explain about alternative shells that can be used. I think that would be better than arbitrarily separating the default shell from "replacement" shells. Herorev 21:27, 26 February 2007 (UTC)[reply]
This looks like it duplicates information from Shell (computing). Therefore, I propose a merge. Any thoughts? -MarkKB 04:54, 9 June 2007 (UTC)[reply]
Agreed, this should be either renamed to something like "Windows shell replacements" or merged into Shell (computing). I'm leaning towards a merge, but definitely, the current name is unsuitable. Nibios 06:46, 19 July 2007 (UTC)[reply]
I stand on renaming: these articles bear different informational context, while "Desktop shell replacement" is just specific for Windows --ΑΜακυχα Θ 03:17, 10 December 2007 (UTC)[reply]
IMO the move is a good idea, see Talk:Desktop shell replacement, but not the merge. The issue with Windows is worthy of an article, rather than cluttering this one with the details. Andrewa (talk) 06:33, 10 December 2007 (UTC)[reply]
Based on what I've read, the lack of discussion, and that the article in question was moved to Windows shell replacement, I'm going to remove the {{mergeto}} and {{mergefrom}} tags. I consider the issue closed. Gh5046 (talk) 07:02, 28 March 2008 (UTC)[reply]

Chronology

Seeing as the CLI came before the GUI shouldn't CLI's be listed in this article first? I'll change it around later if someone else doesn't. Gh5046 15:05, 24 September 2007 (UTC)[reply]

I went ahead and just switched the two. Perhaps like the article the history of the graphical user interface there can be an article for the history of the command line interface. Gh5046 15:27, 24 September 2007 (UTC)[reply]

In the Windows-GUI-section, Cairo links to Cairo (operating system), which has nothing to do with the Cairo shell. As there is no article about the shell, the link should eighter be removed or changed into an external link (like here: Windows shell replacement#Closed source) --77.135.190.50 (talk) 08:50, 8 August 2008 (UTC)[reply]

Sources

It seems this page is light on sources. Can anyone fix it? I'm a bit short on time.

87.194.214.89 (talk) 18:55, 26 November 2008 (UTC)[reply]

In particular, I would like to see a source for the definition of "shell". I think the current definition is too broad for current usage. It would help resolve questions such as the following topic (Windows Explorer is not a Shell.)

Gstory20 (talk) 18:08, 14 May 2016 (UTC)[reply]

Windows Explorer is not a shell

Windoes Explorer cannot be considered a shell.

http://www.techterms.com/definition/shell http://www.webopedia.com/TERM/S/shell.html —Preceding unsigned comment added by 111.64.230.211 (talk) 01:18, 16 August 2010 (UTC)[reply]

Really? From Windows Explorer we see: While “Windows Explorer” is a term most commonly used to describe the file management aspect of the operating system, the Explorer process also houses the operating system’s search functionality and File Type associations (based on filename extensions), and is responsible for displaying the desktop icons, the Start Menu, the Taskbar, and the Control Panel. Collectively, these features are known as the Windows shell. SunSw0rd (talk) 11:18, 5 October 2010 (UTC)[reply]
Windows explorer is IMO file browser. But it could additionally be a window manager, compositor, etc. This additional functions would make it a graphical shell. User:ScotXWt@lk 11:08, 14 June 2014 (UTC)[reply]
Yeah, but explorer.exe is what also displays the taskbar, desktop icons etc. Thus, it is a shell, despite the fact it is some kind of a game of words. — Dsimic (talk | contribs) 16:37, 14 June 2014 (UTC)[reply]
I agree that File Explorer (formerly Windows Explorer) is not a shell but explorer.exe is; only the computer program that explorer.exe implements is Windows Shell, not Explorer, Taskbar or Start screen, although it launches them all.
Microsoft's definition of shell might have been different from the common usage in the past. For example, see DOS Shell, which is not a shell, in spite of its name. But now that they have renamed their file manager File Explorer and introduced Windows PowerShell, maybe they are thinking the common definition is not a bad thing after all.
Best regards,
Codename Lisa (talk) 14:34, 15 June 2014 (UTC)[reply]
Are you sure that "explorer.exe" is not Windows Explorer? At least the processes for shell and Windows Explorer instances in Windows XP were all "explorer.exe", or, if you used defaults, they all were run in one process). — Dmitrij D. Czarkoff (talktrack) 14:47, 15 June 2014 (UTC)[reply]
Simple test: Close all explorer.exe in Task Manager and launch a new one. Instead of launching a Explorer window, it launches the Taskbar. That's because File Explorer is the name of a logical thing we have in our minds: A window with so-and-so toolbars and menu bars that manages files. These logical things, however, are implemented differently. Sometimes a single executable implements a single program, e.g. wordpad.exe = WordPad. Sometimes, many copies of an executable constitute a single program, e.g. a single Internet Explorer (8 or later) or Google Chrome window is maintained by multiple iexplore.exe or chrome.exe in memory. Sometimes, one executable implements many independent programs, e.g. svchost.exe that runs Event Log service and Windows Audio Service in one instance.
But we don't need all these. File Explorer is not a shell. Windows Shell is.
Best regards,
Codename Lisa (talk) 18:44, 15 June 2014 (UTC)[reply]
Thank you, Codename Lisa – it's great to read a description from someone with a much better background in Windows internals. :) So, svchost.exe and explorer.exe are like BusyBoxes on Windows? :)
DOS Shell and a much similar Norton Commander are good examples of what actually isn't a true shell, but the whole thing with PowerShell has been quite interesting since it was made available. Probably Microsoft is finally clear that not everything can be done by clicking around. :)
By the way, Hamilton C shell is also quite interesting, though I have no idea how widely used it is. — Dsimic (talk | contribs) 21:22, 15 June 2014 (UTC)[reply]
@Codename Lisa: I can't do it right now, but the last time I used Windows XP, killing all explorer.exe and launching it via Task Manager resulted in both Taskbar and Windows Explorer window. I remember it because I used to have some problems leading to explorer.exe hanging, so I had to perform this manipulation several times a day. — Dmitrij D. Czarkoff (talktrack) 21:52, 15 June 2014 (UTC)[reply]
With the term "DOS Shell" the people probably don't refer to the program DOS Shell, but its a term for CLI-based shell. This is expert-language for people who don't know anything else but Microsoft products. User:ScotXWt@lk 12:51, 19 June 2014 (UTC)[reply]
Those who write "DOS Shell" with capital S certainly do mean the file manager. Others do not use the word "shell" at all because DOS was too simple to ever make its user feel there is a kernel and a shell. But users did say "DosKey" and "Command.com" (or "the prompt"). Codename Lisa (talk) 19:45, 19 June 2014 (UTC)[reply]

Bad syntax in lead

The article Lead reads:

"A shell is a piece of software that provides an interface for users of an operating system which provides access to the services of a kernel. "

does this simply mean:

"A shell is a piece of software that provides an interface to the services of a kernel, for users of an operating system." –? Trev M   22:32, 1 November 2010 (UTC)[reply]

"Shell (computing)" or "operating system shell"?

  OS   Appli-
cation
Command line
{+
command
line
interpreter
+}
operating
system
shell
GUI +
  not
called
a shell
All the above is user interface

The article is a confusion between two meanings: "operating system shell" (including CLI and graphical ones), and "command line interpreter" (including OS CLIs and application software CLIs). I think that the article should be technically moved to operating system shell, all lists of CLIs have to be merged with list of command-line interpreters, all information about application "shells" should be removed (possibly to command-line interface), and then, the page "shell (computing)" should redirect to a disambiguation page, where not only above meanings will be listed, but also Secure Shell and other things referred to as a "shell". "Shell (computing)" is inherently confusing and should not lead to an article. Incnis Mrsi (talk) 09:19, 12 March 2012 (UTC)[reply]

I agree that the list of command line interfaces should be move to an appropriate article i.e. list of commanf line interfaces. If you do that however, the list of GUIs ought properly to be moved to an appropriate article as well. I disagree that command line interface needs to be split off from this article per se. Also if you want this article to be about just operating system shells then this article ought to be renamed, but a disambiguation page ought to be left for computing shell to describe the myriad uses of the term. Op47 (talk) 13:29, 9 September 2012 (UTC)[reply]
I already wrote just above:
Which "myriad uses" beyond aforementioned three, and also shell account, did you find? So few items as 4 do not require a separate dab page. A dedicated section in shell will be enough, just like the infamous code (computer programming). Incnis Mrsi (talk) 16:28, 9 September 2012 (UTC)[reply]
  • Oppose rename. I think the article is very clear in stating what it's about, namely, "an interface for users of an operating system which provides access to the services of a kernel" and that they "fall into one of two categories: command-line and graphical." Nearly any article can be improved and this one probably could be as well. But what it doesn't need is a new title. Msnicki (talk) 17:06, 9 September 2012 (UTC)[reply]
    The consideration that an article "is very clear in stating what it's about" has nothing to do with WP: Article titles (although I do not agree with Msnicki in that "the article is very clear", anyway). Look on the IPython article, at the very beginning:
Why have we accept that Msnicki knows what is The Very True Shell in Computing better than authors of the article about IPython? Otherwise, a diagnosis is ready: the title is ambiguous. Incnis Mrsi (talk) 18:20, 9 September 2012 (UTC)[reply]
The attitude is unnecessary. We're all anonymous here, each entitled to an opinion and to be treated respectfully. We are expected to assume good faith. I appreciate that you'd like to make a change and if the consensus supports you, we'll do it even over my objection. That should be good enough. Msnicki (talk) 01:45, 10 September 2012 (UTC)[reply]
  • Oppose rename, but massively edit the existing article.
There is a vast literature out there on "shells" as command-line interfaces. There is an equal volume on GUIs, graphical desktops and other graphical user interfaces. The use of "shell" applied to such a graphical interface is almost unheard of. An obscure and obsolete version of OS/2 is the only one I recall.
This article is a nonsense. It presents both command line and GUI, as if the article topic was UI or HCI in general, and it gives equal weight to GUIs under this "shell" label. That's simply wrong. Although at least one graphical shell has used the already-widespread "shell" term for its innovative GUI, this is very much the exception. Claiming that GUIs are described as "shells" such that they deserve equal weight in this article specifically on shells is ridiculous, not to say unsourced. It's also riddled with basic technical errors, such as over-stating the amount of function that's provided by Windows Explorer.
A question of trivial renaming about disambiguators is not the point here (although Shell (computing) better suits our general policy on their technical formatting, as it allows the pipe trick). This article should usefully be re-written to remove most of the coverage of GUIs as being outside its scope. It might instead be renamed as "operating system user interface", which would at least be closer to the scope included at present. Andy Dingley (talk) 13:03, 10 September 2012 (UTC)[reply]
I do not insist on any particular title to move the article to; the only thing I perceive as an important one is making the title "shell (computing)" ambiguous. But I have yet several comments. First, the Andy's perception of "shell" (GUIs are outside its scope, CLIs are inside) is totally opposite to Msnicki's one (an interface for users of an operating system… fall into one of two categories: command-line and graphical). Note that the article about command-line interface already exists. Second, Andy is certainly not right that “the use of "shell" applied to such a graphical interface is almost unheard of”, see Windows shell replacement. Operating system shell or operating system user interface certainly is a valid topic which, in its explicit form, English Wikipedia still misses. BTW ru:Оболочка операционной системы literally translates as "operating system shell". Incnis Mrsi (talk) 14:45, 10 September 2012 (UTC)[reply]
It's not about what I or Msnicki think a "shell" means, it's about what's sourceable. This article is seriously lacking in sources, especially for equating GUIs with the term "shell". Once again, WP is not an acceptable recursive source for WP. Andy Dingley (talk) 15:24, 10 September 2012 (UTC)[reply]
So, suppose that we verified that a sufficient amount of sources with the word "shell" exist for all 3 cells on my diagram. What do you propose to do in this situation? If you agree with me that "operating system UI" must be separated from command-line interface, disregarding terminological issues, then I'll go forth with the semantic separation and then, you can discuss which title would be better for the article about OS UI, and how to mention it from the "shell" dab page. If you do not agree, then we shall continue arguing here. Incnis Mrsi (talk) 15:46, 10 September 2012 (UTC)[reply]
Obviously command lines are radically different to GUIs and both are important. So in terms of delivering good, clear, articles we should probably split the scope on that basis alone. A lightweight overall article for both would be worthwhile, but it's never going to be much more than a navigational aid.
I care very little about the article naming. But if it has to be called "shell", it does need to source that name. The article in its current state is a long way from that. Andy Dingley (talk) 16:58, 10 September 2012 (UTC)[reply]
Existence of the term "Windows shell" is corroborated by MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/bb773177%28v=vs.85%29.aspx
Also, at least one printed book refers to different (CLI and graphical) "kinds of shell" under MacOS. Incnis Mrsi (talk) 19:43, 10 September 2012 (UTC)[reply]
On this point, I would agree with you and disagree in part with Andy. Andy is correct in arguing that the basic claim that there are two kinds of shell should be sourced. But I think he goes too far to extent he seems to be arguing the claim is untrue. I think it is true. I think the two kinds are command line and graphical. I think that is how people understand the term and I say that even though I can remember feeling very uncomfortable with that in the 90s, especially as someone (check my edit history) who really likes command line shells. (Btw, setting aside arguments about WP:OTHERCRAP, I see no conflict between shell as it's understood in this article and the use of the term in connection with IPython. A shell is a layer that lets you manipulate what's beneath it. IPython looks like a shell to me.)
What changed my view, causing me to decide that shells now include graphical shells were two things. The first was realizing I had to concede that graphical is just the other obvious UI paradigm for building a thin layer around everything below; it's not necessarily a limitation on what it does. Also, arguing from WP:COMMONNAME, I think that is how people now use and understand the term, especially in the Windows world, where few users ever touch a command line, yet they do manipulate the system with the explorer and graphical admin tools, etc., and I do hear them call that a shell. Basically, the only thing they really give up are the programming constructs (probably of little interest to most end-users), replaced with multi-select. Msnicki (talk) 21:14, 10 September 2012 (UTC)[reply]
A layer that lets you manipulate what's beneath it has exactly one name, quite simple: user interface. There are two orthogonal classifications of it: by design and by purpose. There are two classes relevant to the word "shell": CLIs (a design) and OS interfaces (a purpose). Let us just separate one from another, and dump the ill-fated title into a dab page via anchored redirect. Do not invent unnecessary complications. Incnis Mrsi (talk) 22:06, 10 September 2012 (UTC)[reply]
No. Msnicki (talk) 22:57, 10 September 2012 (UTC)[reply]
So, if you insist that there exist some notion of the "shell" which is neither operating system shell (an undisputably valid concept), nor command-line interface (with the article already existing), then why is it not the entire "user interface"? Try to propose your definition, preferably not by explicit exclusion of all application non-CLIs. Incnis Mrsi (talk) 09:55, 11 September 2012 (UTC)[reply]
I've given you my answer. I'm satisfied with the article title as it is and I don't find your arguments persuasive. You don't have a consensus and you're not getting one, certainly not by continuing to argue as if you don't think anyone else's opinion could have merit. Personally, I don't think you know what you're talking about. I'm opposed to your proposal. That's pretty much all you need to know. Msnicki (talk) 14:47, 11 September 2012 (UTC)[reply]
  • Oppose: First, the thing is called "shell", not "operating system shell". Second, most (if not all) shells are not tied to any particular operating system. Third, the different between classic shells and programming languages interpreters is really very blurry, so enforcing the difference will lead to more confusion. Overall, the article could benefit from explanation of the problems, but not from this change of name. BTW, GUIs are sometimes called "shells". Some of them are even mostly referred to as shells, eg. Windows 3.1, Workplace Shell — Dmitrij D. Czarkoff (talktrack) 18:57, 11 September 2012 (UTC) updated 19:14, 11 September 2012 (UTC)[reply]
    Which "thing"? Give your definition, please. Incnis Mrsi (talk) 08:53, 12 September 2012 (UTC)[reply]
    Interactive command line interpreter. (ksh(8) – OpenBSD System Manager's Manual says: "ksh is a command interpreter intended for both interactive and shell script use".) — Dmitrij D. Czarkoff (talktrack) 16:33, 13 September 2012 (UTC)[reply]
    I did not ask for reliable sources. BTW, in this context a man page is useless because states something about what some program (such as ksh) is, but does not explain what the concept means in general. I ask for a comprehensive definition. But now, I lean to creation of a clean article from scratch and am not particularly interested in continuation of the dispute. Users, who are interested in Wikipedia making sense, will contribute to an article which makes sense. Those who are willing to keep a WP:DICTIONARY article, will keep an unsense. Incnis Mrsi (talk) 20:24, 14 September 2012 (UTC)[reply]
    BTW the "not tied" argument is completely absurd. A bicycle wheel unlikely is tied to some particular model of bicycle, but it is a wheel for a bicycle, not for a motorcycle, for example. An airstrip is not intended to use with a particular model of airplane, but it is used for airplanes, not sport cars. Cf: an operating system shell is not tied to a particular model of OS, but is the shell of an operating system, not of a video game. Incnis Mrsi (talk) 09:41, 12 September 2012 (UTC)[reply]
    Bicycle wheel in general is definitely not tied to any particular bicycle, but each bicycle wheel is tied to some bicycle. To contrary, shell isn't necessarily tied to operating systems. Python isn't operating system, but it has its shell. That said, Windows Media Center is a graphical shell, as well as some other non-OS software. It may be practical to have separate article on graphical shell, but separating CLI shells of OS from CLI shells of programming languages is at best impractical (though "plain wrong" sounds more appropriate to me). — Dmitrij D. Czarkoff (talktrack) 16:33, 13 September 2012 (UTC)[reply]
    I said what I said: "not tied", as an argument against the term "operating system shell", was absurd. Its absurdity does not depend neither on Python nor on Windows Media Center, only on the incorrect assumption that a term "X’s Y" implies a dependence of Y on some particular instance of X. Also, I spoke about conceptual separation. Dmitrij D. Czarkoff apparently does not understand what means "enforcing the difference" in Wikipedia. It does not mean that any thing must be classified either as A or as B, but not both. It actually means that the statement "Y is A" must have a well-defined predication A, not "maybe A, maybe B. Existence of the current article hinders the purpose of internal links to clarify linked terms. Each link should mean either command-line interface or operating system shell, but now there is not way to link to the OS shell concept without adding a terminological confusion. Unlikely one can demonstrate a link bound to "shell (computing)" where both CLI and OS UI, in one article, represent a desired target. Incnis Mrsi (talk) 20:24, 14 September 2012 (UTC)[reply]
Do you think dismissing other editors' opinions and insisting they don't "understand" stuff is likely to persuade them to your view? I don't. You've got unanimous opposition. Isn't it time to let this go? We decide by consensus and sometimes it goes against you. That's just how it works. Msnicki (talk) 20:41, 14 September 2012 (UTC)[reply]
Incnis Mrsi, you could probably find more sense in my response upon reading it. — Dmitrij D. Czarkoff (talktrack) 00:10, 15 September 2012 (UTC)[reply]
Dmitrij D. Czarkoff introduced three arguments. First one, potentially, is valid with appropriate definition, but such definition is not yet provided. Second one I demonstrated to be a grammatical fallacy. Third one I repudiated on structural grounds (Wikipedia can and does classify concepts, but does not aim to classify each phenomenon). On the other hand, noone of Msnicki, Dmitrij D. Czarkoff and Kvng did not attempt to repudiate our crucial argument about inherent ambiguity of the title "shell (computing)". As a reasonable person can notice, the support-the-mash side is losing by arguments, but does not perform so poorly in numbers, scoring three votes (I do not count Andy Dingley, of course, because he actually favoured the separation). Unfortunately, too many against me and Op47. Incnis Mrsi (talk) 06:08, 15 September 2012 (UTC)[reply]
Incnis Mrsi, this article isn't ambiguous, it covers the single coherent topic (though it omits one of the members). — Dmitrij D. Czarkoff (talktrack) 10:56, 15 September 2012 (UTC)[reply]
I think I understand the proposal. My salient comment (last sentence) is that the organization does not need to change. The rest of my comments are suggestions for alternate means of achieving the goals of the proposal -—Kvng 14:35, 14 September 2012 (UTC)[reply]
  • Comment (I didn't carefully read all comments above, so feel free to ignore this comment as well.) During the Windows 3.1/95 era (their) GUIs where known as shells, today not so much anymore. I've never heard REPLs being referred to as "interactive shells". A shell is always a user interface, but a user interface is not always a shell. There might be other uses of "shells" in computing, so renaming this to Shell (operating system) would do little harm, although I don't think it necessary either. In general it's completely pointless arguing over small issues like the title or lead section of articles that are in as dismal a state as this one. —Ruud 22:31, 11 September 2012 (UTC)[reply]
    There is no internal links bound to your red title, but a plenty of links bound to "operating system shell", hence one should not invent completely new titles. Give your definition of an "[interactive] shell", please. I could make article much better had I know what is it about. As I stated a half-year ago, I see nothing here but a confusion and mixing-up two valid but distinct senses. Incnis Mrsi (talk) 08:53, 12 September 2012 (UTC)[reply]
    A shell is is the user interface to the operating system (or kernel, if you prefer the walnut metaphor). In the narrow sense that may include COMMAND.COM in DOS, sh in Unix and the taskbar and Explorer in Windows 95. In the broad sense it may even include (the user interface) of many of the utilities shipped with an operating system (e.g., FORMAT.COM, mkfs, the "Format Disk" window). It generally does not include all the user interface services an operating system may provide to 3rd party applications. —Ruud 17:38, 12 September 2012 (UTC)[reply]
Definition of 'shell'

shell: n.

        [orig. Multics techspeak, widely propagated via Unix]

        1. [techspeak] The command interpreter used to pass commands to an operating system; so called because it is the part of the operating system that interfaces with the outside world.

        2. More generally, any interface program that mediates access to a special resource or server for convenience, efficiency, or security reasons; for this meaning, the usage is usually a shell around whatever. This sort of program is also called a wrapper.

        3. A skeleton program, created by hand or by another program (like, say, a parser generator), which provides the necessary incantations to set up some task and the control flow to drive it (the term driver is sometimes used synonymously). The user is meant to fill in whatever code is needed to get real work done. This usage is common in the AI and Microsoft Windows worlds, and confuses Unix hackers.

        Historical note: Apparently, the original Multics shell (sense 1) was so called because it was a shell (sense 3); it ran user programs not by starting up separate processes, but by dynamically linking the programs into its own code, calling them as subroutines, and then dynamically de-linking them on return. The VMS command interpreter still does something very like this.

Eric Raymond's Jargon File

Wikipedia content

Instead of our usual "There's an oak tree, a maple tree, a birch tree, a poplar tree, for some reason a coconut tree, a coat tree, a whiffletree ...", how about a little more discussion of "trees that shed their leaves each fall" and a little bit less of a catlog of tree names? Maybe someone coming to this article would like an overview about the general nature of a "shell" instead of a list of names. --Wtshymanski (talk) 17:11, 26 October 2012 (UTC)[reply]

Merger proposal

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Operating system shell article duplicates quite a lot of content already well presented within the Shell (computing) article (particularly the Shell (computing) § Graphical shells section), introducing a potential confusion at the same time. As the Shell (computing) article provides a better structure and carries a more universal title, Operating system shell should be merged into it. Let's discuss. — Dsimic (talk | contribs) 05:18, 20 April 2014 (UTC)[reply]

Argh, there's another article on this? I've only barely been sold on the need for an article here at all; we certainly don't need two. I do think that at least some of that content can be salvaged when it's merged here. Chris Cunningham (user:thumperward) (talk) 10:04, 21 April 2014 (UTC)[reply]
Given that it's unlikely that there will be opposition in principle to a merge, I've gone ahead and carried it out. Some of the imported content is low-quality, but it actuially meshes quite well with what we had here and helps to fill out short sections. There's still a lot of work required here though. Chris Cunningham (user:thumperward) (talk) 10:23, 21 April 2014 (UTC)[reply]
Umh, too much crap went into the destination article. Sorry, but I'll revert the merger changes and do it carefully by hand later today. — Dsimic (talk | contribs) 10:36, 21 April 2014 (UTC)[reply]
Urgh. I fail to see why you bothered wasting everyone's time asking for input, in that case. Chris Cunningham (user:thumperward) (talk) 11:09, 21 April 2014 (UTC)[reply]
Per WP:MERGE I guess. That's why we should wait for opposition until 05:18, 27 April 2014 (UTC). — Dmitrij D. Czarkoff (talktrack) 11:23, 21 April 2014 (UTC)[reply]
Exactly, that's how mergers are to be performed and there should be some time for people to comment, as Czarkoff pointed out. So, let's leave it as-is at least until the end of April. — Dsimic (talk | contribs) 17:12, 21 April 2014 (UTC)[reply]
Dsimic, the merge proposal apparently meets no opposition. I believe you can implement it if you want to do so. — Dmitrij D. Czarkoff (talktrack) 22:49, 1 May 2014 (UTC)[reply]
It seems so. I'll try to do that in the next day or two. — Dsimic (talk | contribs) 23:27, 1 May 2014 (UTC)[reply]
Sorry for the delay, currently the time is a little bit tight on my side, and I'll merge the articles on Sunday. — Dsimic (talk | contribs) 03:15, 3 May 2014 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Diagrams

I agree with Aoidh's opinion that the lead section should show some shell, not a diagram. Naturally, I strongly oppose any usage of misleading File:Linux kernel ubiquity.svg, but the other image – File:Linux kernel and gaming input-output latency.svg – is surprisingly useful, and I think it would be appropriate in "Overview" section, which actually needs to be expanded to discuss the kinds of feedback shells may provide. I would prefer to eventually replace it with some OS-agnostic image, but I couldn't find anything appropriate yet. — Dmitrij D. Czarkoff (talktrack) 12:36, 15 June 2014 (UTC)[reply]

Totally agreed, a diagram in the lead section isn't that useful. Went ahead and added File:Linux kernel and gaming input-output latency.svg as you've suggested – please check it out. — Dsimic (talk | contribs) 22:30, 15 June 2014 (UTC)[reply]
Please, user:czarkoff, can you specify "misleading"? Is this supposed to sound intelligent? Which part of the scheme is "misleading"? An OS-agnostic diagram, addressing both CLI and GUI shells would be fine. For picture, I think you mean screenshots, there are the specific subsections. User:ScotXWt@lk 12:48, 19 June 2014 (UTC)[reply]
I am pretty tired of your WP:IDONTHEAR. Please, see Talk:GNOME Shell#Diagrams for explanation that you have already seen and ignored. And no, screenshots are more appropriate then diagrams in lead. — Dmitrij D. Czarkoff (talktrack) 13:40, 19 June 2014 (UTC)[reply]

Difficult to follow with respect to graphical shells

For me, this article is really hard to follow. It's not clear at all to me what the essential features of a graphical shell are from this article. In particular, I don't know how I would be able to distinguish a graphical shell from a GUI, as they both seem to fill the same function.

Even desktop environment doesn't seem to be clearly distinguished from a graphical shell--I'm guessing the fundamental distinction here is whether or not the desktop metaphor is invoked. Since it's a metaphor, it's boundaries are fuzzy anyway, and I'm not sure it's obvious when this metaphor is being appealed to, as it may be appealed to indirectly or obliquely.

As a third point of reference, how is a graphical shell different from a WIMP interface? I'm thinking that's just a particular form of a GUI, but I really wish this article was better about clear definitions.

The article topic is pretty general, so it is frustrating to see descriptions that appeal to the typical nature of a CLI shell as being reflective of the full generality. Perhaps this article would benefit from a more "motivated" description of the history of the term "shell". That might explain why some things are considered shells, even beyond the scope of the original CLI shells. — Preceding unsigned comment added by 70.247.163.191 (talk) 02:44, 19 June 2016 (UTC)[reply]

cvvvvvvvvvvvvvvvvv