The type of ambiguity you reference perceiving here is best remedied by using such terms as a program,
an executable file, or simply an executable for the one that has/is a path,
versus shell command or even command
when you want to reference everything you type into your command
The index to early printings of The C Programming Language ("K&R",
Prentice-Hall) contained only a single mention of the word command, and
not for that word specifically but for command-line arguments. This
small kernel of meaning provides the critical seed that germinated and
ramified into all later uses. From page 111 of one 1978 printing:
5.11 Command-line arguments
In environments that support C, there is a way to pass command-line
arguments or parameters to a program when it begins executing.
That is, the word command is used uniquely in a shell context (because a shell by definition is a command
interpreter), be that in interactive use or in scripted programming. The authors continue with this example:
The simplest illustration of the necessary declarations and use is the program
echo, which simply echoes its command-line arguments on a single line, separated by blanks. That is, if the command
echo hello, world
is given, the output is
Notice how K&R talk about programs and command lines there. In other words, it’s what IEEE’s POSIX 1003.2 is all about, not what POSIX 1003.1 is. In general terms, Dot-1 covers C programming, while Dot-2 covers shell programming.
And shell programming not C programming is what you’re really talking about here. That’s why the intro to Section 1 of the
Unix Programmer’s Manual mentions commands not function calls:
intro — introduction to general commands (tools and utilities)
The manual pages in section 1 contain most of the commands which comprise
the BSD user environment. Some of the commands included in section 1 are
text editors, command shell interpreters, searching and sorting tools, file
manipulation commands, system status commands, remote file copy commands,
mail commands, compilers and compiler tools, formatted output tools, and
line printer commands.
All commands set a status value upon exit which may be tested to see if the
command completed normally. The exit values and their meanings are
explained in the individual manuals. Traditionally, the value 0 signifies
successful completion of the command.
If you were speaking in 1003.1 lingo, you might call it the string argument
to the system function in the C
library. That's because it is not a
syscall itself but a library function that employs various syscalls
under the hood, one of which is
execve. That syscall takes a constant
char * argument as its first argument, which is the path to the
executable file in the file system.
One published solution consistently uses the following definitions:
A file that is specially marked to tell the operating system that it’s okay
to run this file as a program. Usually shortened to “executable”.
In shell programming, the syntactic combination of a program name
and its arguments. More loosely, anything you type to a shell (a
command interpreter) that starts it doing something. [...]
The values you supply along with a program name when you tell a
shell to execute a command. [...]
The name of the program currently executing, as typed on the command
Taken from the fourth edition of Programming Perl (O’Reilly), and here used
by kind permission of that book’s authors. :).
If you’re lucky, you can find all those yourself, and more, merely by
typing this simple command line into your shell so that it runs the man executable/program for you:
But if you aren't that lucky, you can also find them here.
This could be a shell command:
Notice that nothing was
exec’d there; we’ve just rearranged a file descriptor.
exec 5<&0 # save old stdin
exec 0<&3 # read some_var
exec 0<&4 # read another_var
exec 0<&5 # restore it
So each line in a script is a “command”, even here (where I leave as an exercise to the reader how many actual
execve syscalls it begets when run in full):
dd_noise='^[0-9]+\+[0-9]+ records (in|out)$'
status=`((dd if=$device ibs=64k 2>&1 1>&3 3>&- 4>&-; echo $? >&4) | egrep -v "$dd_noise" 1>&2 3>&- 4>&-) 4>&1`
Taken from the venerable jeremiad Csh Programming Considered Harmful,
again used here by kind permission blah blah blah. :)