Is 'shell' a misnomer ?

chomwitt · 2025-05-28 10:55:45

I think that 'shell' is a semantically coarse word that highlights semantics of enclosure,protection, (maybe thinness) that stuck , and latter its usage was reinforced of the proliferation in unix-textbooks of the classic image of the shell encircling the kernel.

We could of course still use that word but i think the semantics of the 'shell' are not align with the way we use the process 'shell'.

The 'shell' is the default process that a computational system presents to its human user by default.

A user can use the 'shell' to set up workflows of processes. A user can also automate by scripting workflows of processes.

So i think the 'use' entails semantics of control, management , coordination , language intepreter , admininstration , human interface , mediator.

In that context even CLI seems semantically more corect. But still missing some central semantics.

Surely the 'shell' does NOT encirlcle the 'kernel' . A user process started by the shell or automatically when the system boots also is close to the kernel services.

So a 'shell' seems to be a user process that is best suited to a task that others are not. That task is workflow setup , management and control.

Last edited by chomwitt (2025-05-28 11:46:58)

pearmypie · 2025-05-28 14:54:52

In college I've learned that it's called a shell because it's the "exterior"/presentation component of your system. Apart from that, a shell is a command interpreter. There are TUI shells and GUI shells. The former interprets your written commands and the latter interprets so much more than just your keystrokes.

chomwitt · 2025-05-28 16:10:52

If 'shell' means outside-exterior interface of a system to it's user then any user progrram could be seen as 'shell' like.

I agree that CLI-TUI Shell is more suitable.

Shell : exterior interface
UI : interface to whom ? the User
CLI : Its interpreter of commands

But still i think is missing the coordination - orchestrating part of setting up and running workflows using a comp system's resources.

Last edited by chomwitt (2025-05-28 16:11:22)

chomwitt · 2025-05-28 16:20:30

Reading multicians.org/shell and especially the shell related linked paper ti seems that in early 60s in the timesharing era when the 'shell' concept emerged it wasnt about external system aspects or the systems outer layer encircliing the kernel. It seems to me that it was an effort to allow calling 'commands' (user initiated programs from a console) from another program.

I am not sure why the 'shell' word was choosen. But from reading the shell paper doesnt seem plausible to me the idea of creating an outer - interface to the user. The way the ideas are presented its like builing a system that merges interacting and automated use of routines. The word -interface- is used but i think refering to the user.

Then in 64 came the Multics design time, in which I was not much involved, because I had made it clear I wanted to return to France in mid 65. However, this idea of using commands somehow like a programming language was still in the back of my mind. Christopher Strachey, a British scientist, had visited MIT about that time, and his macro-generator design appeared to me a very solid base for a command language, in particular the techniques for quoting and passing arguments. Without being invited on the subject, I wrote a paper explaining how the Multics command language could be designed with this objective. And I coined the word "shell" to name it. It must have been at the end of 64 or beginning of 65.
Louis Pouzin on the Shell origins.

4.1 . We may envision a common procedure called automatically by the supervisor whenever a user types in some message at his console, at a time when he has no other process in active execution under control . This procedure acts as in interface between console messages and subroutines.
The purpose of such a procedure is to create a medium of exchange into which one could activate any procedure , as if it were called from the inside of another program.
Louis Pouzin . The SHELL : A Global Tool for Calling and Chaining Procedures in the System

So you have interactively called programs (commands) and you want to create a way to chain them - use the as parts of a another program. Isnt that a description of today 'shell scripting' ? In that context what we call 'shell' started as a way to make user-interactive programs accessible to automation by being able to became part of a larger program. That is not a 'shell' - outer layer semantics.

Last edited by chomwitt (2025-05-28 16:53:22)

chomwitt · 2025-05-28 18:36:53

So speaking in general we want programs to have hooks and interfaces that allow for interactive use and automate use. Why an effort to achieve that would be called 'Shell' make no sense to me.The subtitle of Louis Pouzin paper 'A Global Tool for Callling and Chaining Procedures in the System' makes more sense.

Last edited by chomwitt (2025-05-28 18:51:13)

chomwitt · 2025-05-28 18:58:24

So how would you call an effort to make some handy tools equipped with automation hooks in order for a robot to use them ?

Automation Interface Hooking System? It's not that the system (tools) didnt have access points before . They just got additional ones in order to be used in a different context . Was a timesharing system shell-less before runcom ?

So the 'shell(in computing) ' is a special kind of human interface and mechanism that allows to create automated workflows of already existing processes.

Last edited by chomwitt (2025-05-28 19:56:50)

MLEvD · 2025-06-03 06:33:58

* switches to ash weeb because it's lighter *

The officially official Devuan Forum!

#1 2025-05-28 10:55:45

Is 'shell' a misnomer ?

#2 2025-05-28 14:54:52

Re: Is 'shell' a misnomer ?

#3 2025-05-28 16:10:52

Re: Is 'shell' a misnomer ?

#4 2025-05-28 16:20:30

Re: Is 'shell' a misnomer ?

#5 2025-05-28 18:36:53

Re: Is 'shell' a misnomer ?

#6 2025-05-28 18:58:24

Re: Is 'shell' a misnomer ?

#7 2025-06-03 06:33:58

Re: Is 'shell' a misnomer ?

Board footer