Shell

HomePage | RecentChanges | EditorIndex | TextEditorFamilies | Preferences

A Shell is a simple TextEditor that executes code on the fly. It is usually used to move files around or feed files to several text manipulation programs, or open them in more extensive editors. This is particularly true on Unix systems (and derivatives) where everything is considerd a file, and files are by preference human readable. Some people also use shells to start programs that have little to do with file manipulation, these would probably be better of with a graphical environment.

A typical shell uses a 'readline' library for input, these libraries in fact provide an stripped down editor that can only edit one line at a time. Most readline libraries either use a subset of the VI keybindings (this is even specified by the POSIX? standard for shells) or a subset of the Emacs keybindings. The bigger shells allow the user to choose between VI and Emacs keymaps.

Of course one can also execute shell commands from the most bigger text editors on unix, also most more advanced text editors have some kind of 'file browse' mode to manipulate the filesystem. So it can be considered to be a matter of taste whether you use a shell from your editor, or an editor from your shell.

Basicly we call our program a shell if it has job-control and handles text from stdin; and we call it a texteditor if it primarily handles text from files (typicly including a file-browse mode, but uses a 'shell out' construct for system commands).


Interesting definition. On mainframe systems, the "shell" if you will can be used as a FullScreenShell?. That is, it is possible to place the cursor anywhere on the screen and execute commands. This is somewhat analogous to cutting and pasting command lines except it is a bit more intuitive I think. The VM/CMS system, for example, has this capability.

Also, the concept of job control in UNIX systems (like Solaris or Linux) is a bit different than on other operating systems.

Finally, I think of the alternative shells that you might find on Unix and DOS that are based on NortonCommander? or XTREE?. These are FileManagers? that people stay in just like Shells.


Hmmmm. "A Shell is a simple TextEditor that executes code on the fly."

Well, true as far as it goes, but it doesn't go nearly far enough.

Fundamentally, the shell is the user's interface with the system, regardless of the form the interface takes. On the old Commodore 64, the built-in BASIC interpreter was the user's shell. Under MS/DOS and Unix/Linux?/BSD, the shell is often a command line, but does not have to be. On a "classic" Mac, there *is* no command line, and the GUI (Finder) is the user's shell. On a Windows machine, the GUI is the shell, and while a CLI is available, many users never use it.

What distinguishes the shell on systems that have a CLI as the default is that the shell is both a command interpreter and a programming language. You can not only execute commands from the shell: you can use a text editor to create scripts written in the shell language, and execute those scripts as programs.

CP/M had a batch processing facility. MS-DOS had a slightly more sophisticated one, whose biggest limitation was no facility for getting input from the user. Unix has a variety of shells, including the Bash, Bourne, C, Korn, Tcsh, and Z shells. the Bourne shell was the original Unix shell, and the Korn and Z shells are supersets adding additional features to the shell language. The C shell was intended to have a shell language with a C like syntax, and tcsh takes that and adds features to make it a better command line interface. The bash shell attempts to combine the best features of all of them.

Just about every system I've seen provides a way to use something other than the default shell. Under MS-DOS, it was possible to specify the desired command interpreter in the CONFIG.SYS file that was read on boot up, and while that was usually COMMAND.COM, it didn't have to be. I used both JP Software's 4DOS (a drop in COMMAND.COM replacement), and the MKS Korn Shell on my old PC under DOS, and had things set up so that I was presented with a login prompt, and what ID I used determined what shell I was placed in.

Win 3.X was essentially a GUI shell on top of DOS, and similar possibilities existed. You could replace Program Manager (the default GUI) with something else, and a variety of things existed. I used a freeware product that tried to make Windows look like the Workplace Shell on OS/2 machines. When Win95 was released, migrating was fairly painless, because WPS for Windows already had many of the features Win95 introduced, like shortcuts on the desktop.

Under *nix running X-Windows, you can have a GUI enviroment, but that's highly configurable. To use X, you must have a window manager and widget set, and most systems offer a choice of the Gnome or KDE environments, with different looks and feels, and you can open up terminal windows with command lines, like doing Start/Run/CMD in Windows, and run your choice of installed shell.

--DMcCunney


HomePage | RecentChanges | EditorIndex | TextEditorFamilies | Preferences
Edit text of this page | View other revisions
Last edited May 29, 2009 9:12 am (diff)
Search: