What is the role/responsibility of a 'shell'? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 7 years ago.

Improve this question 开发者_运维知识库

I have been looking at the source code of the IronPython project and the Orchard CMS project. IronPython operates with a namespace called Microsoft.Scripting.Hosting.Shell (part of the DLR). The Orchard Project also operates with the concept of a 'shell' indirectly in various interfaces (IShellContainerFactory, IShellSettings).

None of the projects mentioned above have elaborate documentation, so picking up the meaning of a type (class etc.) from its name is pretty valuable if you are trying to figure out the overall application structure/architecture by reading the source code.

Now I am wondering: what do the authors of this source code have in mind when they refer to a 'shell'? When I hear the word 'shell', I think of something like a command line interpreter. This makes sense for IronPython, since it has an interactive interpreter. But to me, it doesn't make much sense with respect to a Web CMS.

What should I think of, when I encounter something called a 'shell'? What is, in general terms, the role and responsibility of a 'shell'? Can that question even be answered? Is the meaning of 'shell' subjective (making the term useless)?

Thanks.

---

In Orchard the term "shell" is really more of a metaphor for a scope. There are three nested scopes: host, shell, and work.

The host is a single container that lives for the duration of the web app domain.

The shell is a child container created by the host that is built according to the current configuration. If the configuration is changed a new shell is built up and the existing one is let go.

The work is another a container, created by the shell, that holds the components that live for the duration of a single request.

One nice thing about the use of a shell container it that it helps avoids the use of static variables and the need to cycle the app domain on when configuration changes. Another nice thing is that it enables an Orchard app domain to serve more than one "site" at the same time when the host holds a number of shells and uses the appropriate one for each request.

---

I think that a general meaning for shell would be 'user process that interprets and executes commands'.

1. 'User process': as distinct from a process built into the operating system kernel. JCL in the IBM mainframe world would be hard-pressed to count as a shell.

2. 'interprets and executes': in some shape or form, a shell reads commands from a file or a terminal, and reacts to what is presented, rather than being rigidly programmed to do a certain sequence of commands.

3. 'commands: what the commands are depends on the context. In the standard Unix shells, the commands executed are mainly other programs, with the shell linking them together appropriately. Obviously, there are built-in commands, and also there is usually flow-control syntax to allow for appropriate reactions to the results of executing commands.

In other contexts, it is reasonable to think of other sorts of commands being executed. For example, one could envision an 'SQL Shell' which allowed the user to execute SQL statements while connected to a database.

A Python shell would support Pythonic notations and would execute Python-like statements, with a syntax closely related to the syntax of Python. A Perl Shell would support Perl-like notations and would execute Perl-like statements, ... And so the list goes on. (For example, Tcl has tclsh - the Tcl Shell.)