Do you think the shell is an integral part of the kernel or something that can be substituted by other means of communicating with the OS (GUI)?
I would like to write my own shell in C++, I've had a look at the open group's basic shell specification and it seems to be quite a task to write a powerful unix conformable shell. Additionally I've peeked at the bash source code. I think I'm in need of a tutorial or a smaller shell source code that shows me what I need to think of and how to go about implementing some features that make a shell a powerful tool.
the shell
Re:the shell
While I would say that some form of text-only command processing is important, I don't know if I would use a shell in the classic sense. I am particularly drawn to the idea, used in some experimental OSes (e.g., Oberon) of being able to execute arbitrary text selectably; that is, any text which is selected could be then processed as a shell script (say, right click and drag to select, left click to execute?). This kind of 'visual shell' could easily be the primary command interface, in fact; like in Oberon (or Emacs), things like menu items and icons could be simply triggers for invoking a command or function (scroll bars and such would be special cases, but still basically the same thing). With a suitable menu/icon editor, the users could easily redesign menus on the fly, adding or remove functionality as the need it, and any ordinary utility/function could be used. See Raskin's The Humane Interface for a broader elaboration on this idea.
It would be a Good Thing if it allowed you to pipe arbitrary text streams to the interpreter, so that programs could send scripts to call each other. If you write the interpreter in a general enough fashion, you should get this for free; indeed, if you separate the interpreter from the interface, you would be able to use different scripting languages interchangably. This would also make it easy to provide an interface for remote operations (telnet, etc.). You would want to have suitable security to prevent malicious scripts from running, however.
It would be a Good Thing if it allowed you to pipe arbitrary text streams to the interpreter, so that programs could send scripts to call each other. If you write the interpreter in a general enough fashion, you should get this for free; indeed, if you separate the interpreter from the interface, you would be able to use different scripting languages interchangably. This would also make it easy to provide an interface for remote operations (telnet, etc.). You would want to have suitable security to prevent malicious scripts from running, however.
Re:the shell
Oh, I should mention one important wrinkle in all of this: while it may be tempting to try and simply throw a user front end on top of an ordinary shell or script interpreter, doing so probably would not work with some quite a bit of additional work. The reason for this that, whereas an ordinary shell session has relatively little state or its own (mostly tied up in environment variables and the shell history), a GUI session has a tremendous amount of it - the display image, the open files and applications, occuring events, etc. The scripts (either through the interpreter itself or through implicitly invoked library functions) would need access to this state, in order to perform their functions. At the very least, a library like Tk would have to be available to the scripts for windowing functions.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:the shell
Definitely, the shell should be decoupled from the operating system kernel, and the OS should be able to run even without a shell (if it receives a program to run instead of the initial shell, and that this program is the only one that need to be run here -- say a webbrowser for webbased devices)Baraclese wrote: Do you think the shell is an integral part of the kernel or something that can be substituted by other means of communicating with the OS (GUI)?
Re:the shell
I definitely agree with this "decoupling" of operating system and shell. A shell should just be like any other program, except it's sole job is to help you interface with the computer and the operating system, whether that be to examine the filesystem or run other programs. By tying something like that into the actual operating system, you start to restrict its configureability.
A shell shouldn't be able to do anything the rest of the programs on the computer can't (otherwise it would be impossible to write a replacement shell) so it makes sense to run it as a user program rather than as part of the kernel.
A shell shouldn't be able to do anything the rest of the programs on the computer can't (otherwise it would be impossible to write a replacement shell) so it makes sense to run it as a user program rather than as part of the kernel.