Short answer to your question is "depends on what you mean by shell." Answer for Unix heads is http://multicians.org/shell.html where Louis Pouzin says he made up the name for Multics. We never called the CTSS command processor a shell. When I used CTSS in 1963, command processing was in (wired) code in A-core. A simple program tokenized input lines, looked up the token in A-core tables, and either ran an A-core routine or loaded a command file, passing the rest of the arguments as a string array. To add a command, you had to recompile CTSS. Look at the module COMC in the source. This command language is documented in the "candy stripe" CTSS manual. http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide.pdf About 1964 or 65, COMC was changed to not list the disk loaded commands; if the table lookup failed, COMC looked for a disk file in a system directory, and ran it if it was found. System maintainers could add a command by copying a file into the directory. Command files were in core image format, already loaded and linked. Conventional practice was to make them small and to expand the core image for things like I/O buffers at execution start. Some disk-loaded commands were listed in COMC and flagged as "privileged" so that they could call special supervisor entries to get the supervisor to do things forbidden to regular programs. the LOGIN command was an example: it could read the password file, forbidden to regular users, and could patch the A-core table of logged in users. Louis wrote a disk loaded program called RUNCOM that read command lines from a file, substituted arguments into the command, and requested the supervisor to run them, and then return control to RUNCOM. This is a shell-like function. Noel Morris and I wrote an author-maintained unprivileged B-core CTSS program in 1965 called . SAVED that was also shell-like. It read lines from the terminal, tokenized them, expanded abbreviations and iterations, and ran sequences of commands, and then resumed itself. It had other features such as inter-user text messages. It allowed power CTSS users to extend the system-provided command set with their own set of SAVED files, all treated uniformly. Noel and I also added a facility to CTSS that allowed the system to run batch jobs. The user submitted a RUNCOM file to a queue for later processing, much like Unix CRON. Revised command processing, RUNCOM, and . SAVED are documented in the second edition CTSS manual. http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide_Dec69.pdf Multics had a program known as the shell, which went through a long series of evolutions. Users could replace their command shell. A program called the listener read command lines and fed them to the shell, which tokenized the command lines and found and called individual commands. The argument-substituting run-from-a-file mode of operation of RUNCOM was done by the exec_com command. All of these Multics features and design were familiar to Ken and Dennis when they worked on Multics. You say you have been looking at the CTSS source. You know you can run a simulated 7094 running a simulated CTSS, right? http://www.cozx.com/~dpitts/ibm7090.html regards, tom