Lawrence D'Oliveiro
2024-08-10 06:39:10 UTC
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.
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.