Hubbry Logo
RUNCOMRUNCOMMain
Open search
RUNCOM
Community hub
RUNCOM
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
RUNCOM
RUNCOM
RUNCOM
View on Wikipedia
from Wikipedia
RUNCOM
DeveloperLouis Pouzin
Initial release1963; 63 years ago (1963)
Written in[data missing]
Operating systemCTSS
PlatformIBM 7090, IBM 7094
Available inEnglish
TypeCommand processor
License[data missing]

RUNCOM is a CTSS macro command (script) processor.[1]

History

[edit]

Louis Pouzin created RUNCOM for CTSS circa 1963.[2] He released a paper in 1965 describing a design for the Multics shell which includes a brief description of RUNCOM[3] followed by a second paper he released five days later describing a design for RUNCOM that added commands for control flow, conditional branching and looping.[4]

In the context of Unix-like systems, the term rc stands for the phrase "run commands". It is used for any file that contains startup information for a command.

From Brian Kernighan and Dennis Ritchie:[5][6]

There was a facility that would execute a bunch of commands stored in a file; it was called runcom for "run commands", and the file began to be called "a runcom". rc in Unix is a fossil from that usage.

Tom Van Vleck, a Multics engineer, has also reminisced about the extension rc: "The idea of having the command processing shell be an ordinary slave program came from the Multics design, and a predecessor program on CTSS by Louis Pouzin called RUNCOM, the source of the '.rc' suffix on some Unix configuration files."[7]

This is also the origin of the name of the Plan 9 from Bell Labs shell by Tom Duff, the rc shell. It is called "rc" because the main job of a shell is to "run commands".

While not historically precise, rc may also be expanded as "run control", because an rc file controls how a program runs. For instance, the editor Vim looks for and reads the contents of the .vimrc file to determine its initial configuration. In The Art of Unix Programming, Eric S. Raymond consistently refers to rc files as "run-control" files.

Usage

[edit]

Background

RUNCOM is not a shell in the sense of the UNIX shell. When a user type commands into CTSS they go to the supervisor (kernel), not any UNIX-shell-like program. Users cannot type commands into RUNCOM, it processes disk files. CTSS files have first name and a second name separated by spaces, e.g. FOO BCD, similar to CMS.

Description of RUNCOM

RUNCOM command chains also known as macro-commands (both terms mean scripts) are files with a second name of either RUNCOM or BCD which contain zero or more lines. Lines in the script are either blank lines, comments, regular commands (the kind that could be entered on the supervisor's command line) or the pseudo-command (command built into RUNCOM only) CHAIN.

Comments start with either $ or * as the first character of the line. Comments using $ are printed (including the $) when RUNCOM runs while ones with * are not printed at all. Parameter substitution does not occur in comments.

When a user invoke RUNCOM, the arguments (parameters) to it must first start with the first name of the file containing the script. If a user invoke RUNCOM without any arguments it prints some instructions on how to use it and stops, returning the user to the supervisor's (system's) command line. The remaining arguments, if any, are either command names, values to be used as arguments in the script or the strings (NIL) or (END) including the parenthesis.

In the script, CHAIN give names to arguments which were used on the command line when RUNCOM was called, e.g. putting CHAIN LALA FAFA in the script and invoking RUNCOM XYZZY 3 will cause LALA in the script to be substituted into a 3 when it is used in any lines that come after CHAIN while FAFA will remain FAFA as RUNCOM was invoked without specifying anything for it.

If an argument to RUNCOM is (NIL), a positional parameter denoted as an argument to CHAIN in the script will be expand into nothing, e.g. CHAIN ALPHA BETA GAMMA combined with RUNCOM A (NIL) B will cause ALPHA to be substituted with A and GAMMA to B while BETA will be removed from any command that follows CHAIN in the script.

If a RUNCOM argument is (END) the corresponding CHAIN argument will be treated as (NIL) and all subsequent arguments will also be treated as (NIL).

Any parameter to CHAIN can be used as a command name in the script, i.e. can come first before any arguments. An example would be RUNCOM SCRIPT LISTF combined with CHAIN CMD followed by CMD at the start of a following line. CMD will be substituted into LISTF which will list the files in the directory (like the Unix ls command).

Once the substitutions have been completed, RUNCOM sends the commands to the SCHAIN library subroutine which is available to other programs as well.[1]

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

RUNCOM

View on Grokipedia
from Grokipedia
RUNCOM was a groundbreaking command script interpreter developed by French engineer Louis Pouzin in 1963–1964 for the (CTSS), an early operating system at MIT's Computation Center. It allowed users to create files containing sequences of CTSS commands with parameter substitution, enabling the of repetitive tasks such as file renaming, moving, updating, compiling, and system maintenance. Pouzin coined the term "shell" to describe RUNCOM, likening it to a lightweight interface that encapsulated and executed command scripts much like subroutine libraries in programming. Developed amid the rapid evolution of systems in the early , RUNCOM addressed the limitations of manual command entry on CTSS, which ran on a modified 7094 computer and supported multiple users interactively. By permitting overnight execution of scripts, it boosted productivity for system administrators and programmers handling large directories of files, quickly becoming a popular tool within the MIT community. Pouzin's stemmed from his frustration with writing dozens of individual commands, prompting him to envision commands as modular building blocks. RUNCOM's design directly influenced subsequent command interpreters, serving as the conceptual precursor to the shell in the operating system, which Pouzin helped develop starting in 1965. This shell, in turn, inspired the created by and others in the early , establishing the shell as a core component of systems. Today, the term "shell" remains the standard for command-line interfaces in operating systems worldwide, underscoring RUNCOM's enduring legacy in computing history.

History

Origins in CTSS

The (CTSS), developed at MIT in the late and early , represented a pioneering effort in multi-user operating systems, enabling interactive computing on an 7094 mainframe through innovations like disk-based file storage and remote terminal access. As one of the first systems to support multiple simultaneous users, CTSS highlighted limitations in command execution, particularly for repetitive tasks that required manual intervention in a shared environment. To address these challenges, Louis Pouzin, a member of MIT's computer center staff, created RUNCOM circa 1963 as a macro command processor integrated into CTSS. Pouzin designed RUNCOM specifically to automate sequences of commands, serving as an early tool for scripting in a system that lacked native built-in scripting capabilities. This innovation allowed users to streamline workflows, such as file management or program compilation, by substituting arguments into predefined command sets, thereby reducing the tedium of interactive repetition. RUNCOM was implemented in the MAD (Michigan Algorithm Decoder) language, which allowed for faster and more maintainable code. In its initial form, RUNCOM operated by processing command macros stored in disk files rather than supporting real-time interactive behavior, enabling users to submit scripts for sequential execution. This file-based approach facilitated overnight , permitting users to initiate long-running tasks and depart, which significantly enhanced productivity in CTSS's resource-constrained setting. Pouzin later described it as a "sort of shell driving the execution of command scripts, with argument substitution," underscoring its foundational role in command automation.

Development and Enhancements

RUNCOM was initially implemented in CTSS in 1963–1964 as a basic macro processor for command substitution and automation. By 1965, as development began, Pouzin shifted focus to designing an advanced shell for the new , building on RUNCOM's concepts. His April 1965 papers, including "The SHELL: A Global Tool for Calling and Chaining Procedures in the " and "RUNCOM - A Macro-Procedure Processor for the 636 ," outlined these proposals for the GE-636 in early design. Within CTSS, RUNCOM saw limited further development, as Pouzin departed MIT in mid-1965.

Design and Functionality

Core Architecture

RUNCOM functioned as a command script interpreter within the (CTSS), designed to automate sequences of commands by processing predefined scripts rather than providing an interactive like modern shells. Unlike contemporary shells that interpret user input in real time and maintain an execution environment, RUNCOM read scripts sequentially from disk and submitted expanded command lists directly to the CTSS for processing, emphasizing over interactive dialogue. This design, developed by Louis Pouzin in 1963-1964, treated scripts as sequences of CTSS commands to streamline repetitive tasks in the environment. At its core, RUNCOM read input sequentially from disk files with secondary names such as RUNCOM or BCD, which contained sequences of CTSS commands stored line by line, often with placeholders for parameters. These files, located in user or system directories, were accessed using CTSS file input routines like RDLINA or supervisor buffers, processing each logical BCD record as a distinct request. Upon invocation via a command like RUNCOM followed by the , the processor expanded the script by substituting formal arguments (e.g., dummy symbols in commands) with actual values provided at runtime. Parameter substitution formed the central mechanism, enabling parameterized scripts by replacing placeholders with user-supplied values prior to execution. The expanded output was then directed to the SCHAIN library subroutine, which managed command chaining by storing the list in a stack and interfacing with the CTSS command processor for sequential execution. This integration relied on supervisor calls, such as TSX RUNCOM, to transfer control, ensuring the processed commands were treated as standard CTSS requests without RUNCOM maintaining its own interpretive loop. RUNCOM operated primarily in batch mode, executing scripts autonomously once initiated, but supported limited interactivity through commands like QUES for conditional prompts during processing. It processed commands as if entered directly at the console but handled interruptions via mechanisms like SAVFIL and RERUN, preserving core images in temporary SAVED files for resumption. This batch-oriented approach, with optional interactive elements, aligned with CTSS's emphasis on efficient resource sharing, delegating all execution to the system's command executor rather than embedding environmental state management within RUNCOM itself.

Script Processing Mechanisms

RUNCOM processes scripts by reading commands sequentially from disk files with secondary names such as RUNCOM or BCD, executing them as a chain of CTSS commands. Each line in the file represents a single command, with arguments separated by spaces; blank lines are ignored during processing. The system initiates execution via a RUNCOM command followed by optional arguments, terminating upon reaching the end of the file or an explicit (END) marker. The parameter substitution process involves replacing placeholders, or dummy symbols, with actual values provided at invocation, prior to submitting the expanded commands to the CTSS for execution. This substitution occurs within pseudo-commands, enabling parameterized scripts; for instance, a command such as FILE (NIL) (END) ED FILE MAD would replace dummy arguments in the file's commands with user-supplied values. The expanded script is then processed line by line, preserving the core image and machine state through temporary files to ensure continuity across compatible commands. Support for comments allows users to include non-executable lines in scripts, with lines beginning with *** fully ignored during processing and those starting with treatedascommentsthatareprintedtotheconsolebutnotexecuted.Thismechanismfacilitates[documentation](/page/Documentation)and[debugging](/page/Debugging)withoutalteringscriptflow;forexample,atreated as comments that are printed to the console but not executed. This mechanism facilitates [documentation](/page/Documentation) and [debugging](/page/Debugging) without altering script flow; for example, a line might output a descriptive message like "START′X′FORBOOKFAPSTART 'X' FOR BOOK FAP" during runtime. Control structures in RUNCOM provide basic flow management, enabling conditional execution through commands like QUES, which checks conditions such as file existence and branches accordingly—for instance, prompting "FILE ALPHA BETA NOT FOUND" if absent. Nesting and recursion of RUNCOM calls within chains support more complex sequences, though explicit looping is not natively implemented and relies on repeated chaining. These features allow for rudimentary decision-making and iterative-like behavior in automated tasks. Processed commands are routed through the CHAIN mechanism for interpretation by the CTSS command supervisor, directing output to the user's console in standard format, such as "W t" for wait states or "R t1 + t2" for ready messages. Additional output from utilities like RUNPRT displays substituted parameters in lines limited to 14 words, while status queries from QUES print interactive prompts like "DO YOU WISH TO PROCEED?" Upon completion, control returns to the caller, potentially leaving a final SAVED file representing the dormant system state.

Usage

Basic Syntax and Commands

RUNCOM scripts in the Compatible Time-Sharing System (CTSS) are executed using the RUNCOM command followed by the script's filename, such as RUNCOM SCRIPT, which triggers the sequential processing of commands stored in the file as if entered interactively at the console. Scripts are saved as disk files with a user-defined primary name and a secondary name of RUNCOM, BCD, or SAVED to enable recognition by the RUNCOM processor; for instance, a file named SCRIPT RUNCOM or X BCD follows CTSS's two-word naming convention, where names are right-adjusted and blank-padded. These files must be in BCD (Binary Coded Decimal) format, either line-marked or line-numbered, to ensure proper reading and execution. The basic structure of a RUNCOM script consists of a simple text file containing one CTSS command per line, executed in sequence without branching unless specified by core commands; blank lines are ignored during processing. Comments are supported using $ to denote lines that print during execution or *** for lines that are entirely skipped, facilitating documentation within the script. Simple macros can be incorporated via standard CTSS commands like CHAIN for basic symbol definition, though advanced substitution is handled separately. A minimal RUNCOM script without parameters might automate a compilation sequence, as in the following example saved as SCRIPT RUNCOM:

EDL FILE1 MAD MAD FILE1 LOADGO FILE1

EDL FILE1 MAD MAD FILE1 LOADGO FILE1

Invoking this with RUNCOM SCRIPT would edit, assemble, and load-execute the file FILE1 in MAD language, streamlining repetitive development steps.

Parameter Handling and Chaining

RUNCOM supported parameter substitution to enable dynamic scripting, allowing users to pass arguments at invocation that were replaced by placeholders within the script. Positional parameters were denoted by $1, $2, and so on, corresponding to the first, second, and subsequent arguments provided when executing a RUNCOM file, such as RUNCOM scriptname arg1 arg2. These substitutions facilitated customization of CTSS commands by incorporating user-supplied inputs directly into command lines, with excess blanks removed and a single space inserted between parameters for clean execution. Arguments longer than six characters were truncated from the left, limiting their utility in contexts requiring full identifiers. The command extended this capability by linking multiple scripts or transferring control to another file, enabling sequential execution of command sequences for complex workflows. In a RUNCOM file, CHAIN could specify up to five commands per line, with dummy symbols like ALPH or BET serving as placeholders for arguments that were substituted at runtime. For instance, a script might include CHAIN ALPHA MAD RESUME, where ALPH and MAD were replaced by provided arguments. This mechanism preserved the core image between compatible commands (e.g., those using LOAD-SAVE pairs), allowing chains to maintain system state across invocations. Additionally, the SCHAIN subroutine call, like A = SCHAIN. (FILNAM, ARG1, ARG2), executed chains with parameter substitution in a programmatic context. Examples of parameterized scripts illustrate practical applications in CTSS environments. A simple script file named GREET BCD containing ECHO Hello $1 would output "Hello USER" when invoked as RUNCOM GREET USER, substituting the user's name into the ECHO command for personalized feedback. For more involved tasks, a script could chain file operations: CHAIN SPLIT FIL1 N1 COMBIN FIL1 N2, run as RUNCOM process datafile 100 200, where $1 (datafile) is split at line 100 ($2) and recombined up to line 200 ($3), automating data processing without manual intervention each time. Such substitutions integrated seamlessly with CTSS utilities like EDIT or LOAD, enhancing script reusability for repetitive maintenance. Despite these features, RUNCOM's parameter handling had notable limitations, lacking full variable scoping and supporting only basic branching rather than complex conditionals. Parameters were strictly positional with no mechanism for named variables or reassignment, restricting scripts to linear or simply nested flows without advanced logic like multi-way decisions. Command buffers were capped at 20 words, chains at five commands per line, and temporary files generated during execution (e.g., ...00n [SAVED](/page/Saved!)) risked loss without explicit preservation via SAVFIL, further constraining long-running or deeply nested operations. Special arguments like (NIL) for ignoring inputs or (END) for termination provided minimal flexibility but did not overcome the absence of structures.

Legacy and Influence

Impact on Multics

The concepts underlying RUNCOM significantly shaped the design of the operating system's command facilities, particularly through Louis Pouzin's proposals in the mid-1960s. In 1965, Pouzin authored two key Design Notices (MDNs) that outlined a command interpreter inspired by his earlier RUNCOM work in CTSS: MDN-4, "The SHELL: A Global Tool for Calling and Chaining Procedures in the System," which introduced the "shell" as a mechanism for linking procedures and handling user commands, and MDN-5, "RUNCOM: A Macro-Procedure Processor for the 636 System," which detailed macro-processing techniques adapted for ' GE-645 hardware precursor. These documents proposed treating commands as programmable macros, enabling users to automate repetitive tasks in a environment. Integration of RUNCOM-like features into Multics began with the development of its command language, where Pouzin's ideas for macro expansion and parameter substitution were directly incorporated to create a flexible scripting system. The shell, implemented around 1965-1966 by Glenda Schroeder of MIT in collaboration with GE engineers, built on Pouzin's designs by providing a runtime environment for executing command scripts stored in BCD files, much like RUNCOM's file-based invocation. This shell acted as an intermediary between user input and system primitives, using recursive macro calls to process commands dynamically and support administrative functions such as file management and process control. For instance, meta-arguments like (SAVE) for stack preservation and (MORE) for multi-line input, along with (LOOP) for iterative expansion, facilitated chained command sequences without manual re-entry. Specific adaptations in drew from RUNCOM's chaining mechanisms to enhance system usability for multi-user scenarios. Commands could invoke sequences via the shell's automatic procedure linking, with options like (LOOP) for iterating over parameter lists and control words such as (SKIP) and (STOP) for bypassing or halting parts of macros, enabling efficient handling of administrative tasks such as and . Expansion features permitted dynamic substitution of formal arguments (e.g., replacing placeholders like "" with actual values like ""), which streamlined complex operations in Multics' and resource-sharing model. These elements predated more formalized interpreters in later systems, emphasizing modularity and user extensibility. RUNCOM's influence played a pivotal role in ' evolution as a pioneering OS, serving as a precursor to structured command interpreters that prioritized procedural . By embedding macro-processing into the command language, achieved greater consistency in input-output handling and process management, as detailed in Pouzin's shell proposal, which advocated for a "general procedure-linking tool" to unify user interactions with system calls. This foundation contributed to ' emphasis on secure, scalable command execution, influencing its development from 1965 onward and highlighting RUNCOM's transition from CTSS scripting to a broader OS command paradigm.

Adoption in Unix-like Systems

The "rc" suffix commonly used in Unix-like configuration files originated from the "runcom" command-script feature of CTSS, a concept adapted by early Unix developers including , , and Tom Van Vleck for initialization purposes. As noted by Kernighan and , early Unix systems employed "rc" to denote files containing startup commands, such as the .profile file in the , which executes user-specific environment setup upon login. Tom Van Vleck further recalled that the extension reflected the idea of treating the command-processing shell as an ordinary user program parsing and executing lines from files, a design principle carried over from influences. RUNCOM's influence extended to Unix shells starting with Ken Thompson's shell in 1971, which incorporated basic script-like startup mechanisms for automating command sequences, drawing conceptual inspiration from RUNCOM's macro processing via the shell. This evolved in the of 1977, where .profile formalized the execution of initialization commands to configure the user environment, including path settings and aliases, much like RUNCOM's role in batching repetitive tasks. Specific examples of this legacy include .bashrc in the Bash shell, which sources commands for interactive non-login sessions to customize prompts and variables, and .vimrc in the Vim editor, which processes macro-like instructions for editor configuration and key mappings. In modern Unix-like systems, RUNCOM's conceptual foundation persists through the rc shell in Plan 9, developed by Tom Duff, which explicitly revives "rc" as a full command interpreter emphasizing simple scripting and list processing for environment control, akin to RUNCOM's original macro expansions. This influence is evident in post-Unix evolutions across distributions, such as Debian's use of rc files in package maintenance scripts for dependency handling, and BSD variants like , where /etc/rc.conf centralizes system initialization parameters through command execution.
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.