Implicit Versus Explicit “Run” Command

[Lawrence D'Oliveiro]

Quite a few operating systems, including DEC ones, required you to invoke
an explicit “run” command in order to run one of your own programs, e.g.

RUN MYPROG

or

R MYPROG

(Some DEC systems had both commands, with slightly different meanings. And
there was even

MCR MYPROG

Guess that extra twists that brought to the table?)

I think this sort of thing was de rigueur among batch OSes as well, where
the job-control system always required some explicit “load” or “run” or
“exec” command (or whatever it was called) to run a user program.

Unix was different in this regard (was it the pioneer?). The usual action
of the shell (apart from special cases like built-in commands etc) was to
interpret the first word of a command line as the name of a program to
execute. Not only that, if this was a word with no pathname separators in
it, it was then prefixed in turn by each element of the “search path” (a
second, confusing use of the term “path”), to try to find the actual
executable to run. This made things very convenient for running, not just
standard system commands, but ones defined in a custom user/installation
environment as well.

When Gary Kildall created CP/M, he was heavily influenced by DEC OSes, in
terms of file/device specs etc. Yet he didn’t copy the RUN command:
instead, he brought in the Unix-style interpretation of the first word as
the name of a file to be implicitly run. I don’t think original CP/M had
the “search path” concept (without directories, there wouldn’t have been
any point), but it did instead try different filename extensions,
namely .COM for machine-code executables and .BAT for files containing CLI
commands. And the basics of this idea flowed through into MS-DOS.

Microsoft then introduced the feature (certainly in Windows at some point,
possibly in MS-DOS before that) of third parties being able to register
additional extensions with the executable-search system, that would invoke
alternative interpreters that were installed. E.g. if a .PY or .PYW file
was found, then the Python interpreter would be invoked for that file
(trivia question: why two different extensions?).

*nix systems never had such an extension-matching system, because they
never had extensions as a distinct part of a filespec. Instead, OSes like
Linux allow the registration of alternative interpreters (the “binfmt”
mechanism), but the association with the right interpreter is defined, not
by the filename extension, but by a signature within the file itself. This
does have the nice consequence that the user doesn’t need to know what
language or development system was used to implement a particular command
when trying to use it.

[John Dallman]

I don't think original CP/M had the _search path_ concept

It didn't.

but it did instead try different filename extensions, namely
.COM for machine-code executables and .BAT for files containing
CLI commands. And the basics of this idea flowed through into MS-DOS.

CP/M ran .COM files, but there was no filename extension that caused a
file to be interpreted as CLI commands. You could do that via SUBMIT.COM,
and the conventional extension for its command files was .SUB, but the
only way to run them was with SUBMIT.COM.

http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch1.htm#Section_1.6.7

.BAT was an addition in MS-DOS or possibly its immediate ancestor, 86-DOS.


John

[John Dallman]

Post by Lawrence D'Oliveiro
Quite a few operating systems, including DEC ones, required you to
invoke an explicit _run_ command in order to run one of your own
programs, e.g.

A friend used to work on Ferranti Argus computers for the UK's national
electric power company, the Central Electricity Generating Board. As I
remember, they had different prefix characters on the command line for:

* Command interpreter built-ins.
* Machine code programs.
* Scripts.

I suggested writing a front-end for the command interpreter that would
search directories for the different kinds of file and run them with the
correct prefix.

John

[Lynn Wheeler]

Post by Lawrence D'Oliveiro
When Gary Kildall created CP/M, he was heavily influenced by DEC OSes,
instead, he brought in the Unix-style interpretation of the first word
as the name of a file to be implicitly run. I don’t think original
CP/M had the “search path” concept (without directories, there
wouldn’t have been any point), but it did instead try different
filename extensions, namely .COM for machine-code executables and .BAT
for files containing CLI commands. And the basics of this idea flowed
through into MS-DOS.

Gary was at NPG school and working on IBM CP67/CMS ... some of the MIT
7094/CTSS people had gone to 5th flr for multics and others went to the
4th flr to IBM science center and did CP40/CMS ... CMS (cambridge
monitor system) was originally developed to run on real 360/40 ... while
they were doing 360/40 hardware mods to support virtual memory ... and
then ran in "CP40" (control program 360/40) virtual machines (CP40/CMS
morphs into CP67/CMS when 360/67 standard with virtual memory became
available, later morphs into vm370/cms ... where "cms" becomes
conversational monitor system).

CMS search order as "P" filesysteam originally 2311 (then minidisk
when CP40 virtual machines became available) ... more details:
https://bitsavers.org/pdf/ibm/360/cp67/GY20-0591-1_CMS_PLM_Oct1971.pdf

filesystem/disks "pg4" (PDF13), "P" (primary user), "S" (system), then
possibly "A, B, & C" user files, "T" (temporary/work).

filesystem/disk search order "pg34" (PDF43): P, T, A, B, S, C

Execution control "119" (PDF130) executable, type: "TEXT" (output of
compiler/assembler), "EXEC" (aka shell scripts), and "MODULE" (memory
image) ... if just filename specified (& not type specified) ... it
searches for filename for each type ... in filesystem/disk order
... until match found.

[Johnny Billquist]

I think you got it slightly backwards in a way.

Unix was aiming to be very minimalistic. DEC OSes (as an example) had
command line interpreters with lots of commands and functions. Some of
those commands could very well lead to programs being executed, since
not all functionality was necessarily built into the CLI itself.

However, in order to really be that minimalistic, Unix also had the
shell be very minimalistic. Thus almost no commands were built in or
understood by the shell itself. And that led to the solution of instead
having almost all commands (and specifically any command not understood
by the shell) try to run that command as a program instead, to still
have something that feels like a shell with a rich set of commands
available.

And that then led to the fact that any program you want to run is
basically done by just typing the executable file name directly.

Of course with the caveat if you name a program the same as some
built-in command (or the same as some other program that comes earlier
in the search path) means you'll not that easily run your program.

As for the "MCR PROGRAM" in VMS in order to run programs, that's a bit
of confusion and inheritance from RSX. It's not actually any kind of
alias for "RUN" as such, but under RSX, if you were using DCL, but
wanted to give a command to MCR (which was the system CLI), you prefixed
it by "MCR", and basically MCR is mostly running programs for all
commands you give as well (in RSX). So VMS actually used to have the MCR
CLI as well, and kept the syntax to invoke MCR commands from DCL that
way. But since VMS is not RSX, in VMS is just becomes a case of invoking
the program (it's still sortof how MCR works under VMS).

Johnny

Post by Lawrence D'Oliveiro
Quite a few operating systems, including DEC ones, required you to invoke
an explicit “run” command in order to run one of your own programs, e.g.
RUN MYPROG
or
R MYPROG
(Some DEC systems had both commands, with slightly different meanings. And
there was even
MCR MYPROG
Guess that extra twists that brought to the table?)
I think this sort of thing was de rigueur among batch OSes as well, where
the job-control system always required some explicit “load” or “run” or
“exec” command (or whatever it was called) to run a user program.
Unix was different in this regard (was it the pioneer?). The usual action
of the shell (apart from special cases like built-in commands etc) was to
interpret the first word of a command line as the name of a program to
execute. Not only that, if this was a word with no pathname separators in
it, it was then prefixed in turn by each element of the “search path” (a
second, confusing use of the term “path”), to try to find the actual
executable to run. This made things very convenient for running, not just
standard system commands, but ones defined in a custom user/installation
environment as well.
When Gary Kildall created CP/M, he was heavily influenced by DEC OSes, in
instead, he brought in the Unix-style interpretation of the first word as
the name of a file to be implicitly run. I don’t think original CP/M had
the “search path” concept (without directories, there wouldn’t have been
any point), but it did instead try different filename extensions,
namely .COM for machine-code executables and .BAT for files containing CLI
commands. And the basics of this idea flowed through into MS-DOS.
Microsoft then introduced the feature (certainly in Windows at some point,
possibly in MS-DOS before that) of third parties being able to register
additional extensions with the executable-search system, that would invoke
alternative interpreters that were installed. E.g. if a .PY or .PYW file
was found, then the Python interpreter would be invoked for that file
(trivia question: why two different extensions?).
*nix systems never had such an extension-matching system, because they
never had extensions as a distinct part of a filespec. Instead, OSes like
Linux allow the registration of alternative interpreters (the “binfmt”
mechanism), but the association with the right interpreter is defined, not
by the filename extension, but by a signature within the file itself. This
does have the nice consequence that the user doesn’t need to know what
language or development system was used to implement a particular command
when trying to use it.

[Peter Flass]

Post by Lawrence D'Oliveiro
Unix was different in this regard (was it the pioneer?). The usual action
of the shell (apart from special cases like built-in commands etc) was to
interpret the first word of a command line as the name of a program to
execute. Not only that, if this was a word with no pathname separators in
it, it was then prefixed in turn by each element of the “search path” (a
second, confusing use of the term “path”), to try to find the actual
executable to run. This made things very convenient for running, not just
standard system commands, but ones defined in a custom user/installation
environment as well.

Like the rest of unix, this came from Multics.

[Lynn Wheeler]

Post by Peter Flass
Like the rest of unix, this came from Multics.

some of it tracks back to CTSS, some of the CTSS people went to 5th flr
and multics ... others went to 4th flr and ibm science center doing
cp40/cms ... which morphs into cp67/cms and then vm370/cms.

[Sebastian]

Post by Lawrence D'Oliveiro
Microsoft then introduced the feature (certainly in Windows at some point,
possibly in MS-DOS before that) of third parties being able to register
additional extensions with the executable-search system, that would invoke
alternative interpreters that were installed. E.g. if a .PY or .PYW file
was found, then the Python interpreter would be invoked for that file
(trivia question: why two different extensions?).

I can tell you this wasn't how DOS worked. The extensions COM, EXE, and BAT
were hard-coded into COMMAND.COM. I changed them with a hex editor once
and created a version of COMMAND.COM that used different extensions.