Disambiguating the word "command" in Linux

Question

The word command refers to two different concepts in Linux:

1. An executable program, such as grep (or a shell built-in, such as cd). Example usage: "Here are the top 10 Linux commands you should learn."
2. A full text string sent to the shell for execution, such as grep com /etc/hosts. Example usage: "Type a Linux command and press Enter."

Does anyone have any best practices for avoiding this ambiguity when writing prose about Linux commands? Here are some attempts I've rejected already:

• Using the word program or executable for meaning #1. It's inaccurate for shell built-ins.
• Using the phrase command line for meaning #2. That's confusing because "command line" is also a synonym for "shell."
• Using the phrase command string for meaning #2. It's imprecise because both #1 and #2 are strings.

Any advice appreciated.

Answer 1

POSIX refers to the things that are like grep and cd as "utilities", and reserves "command" for the instructions. Used consistently, these terms are unambiguous.

---

To address your cases in turn

1. "An executable program, such as grep (or a shell built-in, such as cd)" is a utility:

   Utility A program, excluding special built-in utilities provided as part of the Shell Command Language, that can be called by name from a shell to perform a specific task, or related set of tasks.

   Which is further clarified with:

   The system may implement certain utilities as shell functions or built-in utilities

   to be explicit that this incorporates ordinary utilities like true that are commonly found as shell builtins.

   Formally, "special built-in utilities" are separated from utilities not further specified; these are things like break, ., eval, set, and trap, which affect the shell's internal state, but they do not include cd, which is a regular built-in. Outside of the nuanced needs of the specification (certain variable assignment behaviour differs and they are not available with execvp), "utility" suffices to cover both categories at the user level. Articles of shell syntax such as if and while are not utilities at all.

2. "A full text string sent to the shell for execution, such as grep com /etc/hosts" is a command:

   Command A directive to the shell to perform a particular task.

   Commands do include simple commands like grep com /etc/hosts, pipelines, and compound commands like if constructs and grouping commands with ( ... ), but the word "command" never refers to a utility itself. Within a command, a command name may appear that identifies a utility or a function: the command name in grep com /etc/hosts is grep, referring to the grep utility.

---

Vernacular uses of "command" to mean a utility or function may be disambiguated by context, but the formal meaning is only of an instruction. If total avoidance of ambiguity is required, you can consistently use "utility" and "command" for those two roles.

You probably can't expect users to make that distinction themselves, though, so search-engine-optimised "top 10 Linux commands" articles are probably making the right choice for their incentives.

Answer 2

^_SUMMARY

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 line when you want to reference everything you type into your command interpreter.

---

Historical Context

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

 hello, world

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:

NAME

intro — introduction to general commands (tools and utilities)

DESCRIPTION

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.

Published Solutions

One published solution consistently uses the following definitions:

executable file

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”.

command

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. [...]

command-line arguments

The values you supply along with a program name when you tell a shell to execute a command. [...]

command name

The name of the program currently executing, as typed on the command line. [...]

        ^{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:

man perlglossary

But if you aren't that lucky, you can also find them here.

Shell Commands

This could be a shell command:

exec 2>errs.out

Notice that nothing was exec’d there; we’ve just rearranged a file descriptor.

Ditto here:

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):

#!/bin/sh
device=/dev/rmt8
dd_noise='^[0-9]+\+[0-9]+ records (in|out)$'
exec 3>&1
status=`((dd if=$device ibs=64k 2>&1 1>&3 3>&- 4>&-; echo $? >&4) | egrep -v "$dd_noise" 1>&2 3>&- 4>&-) 4>&1`
exit $status

_{Taken from the venerable jeremiad Csh Programming Considered Harmful, again used here by kind permission blah blah blah. :)}

Answer 3

A rather simple solution (and the standard philosophic and linguistic dodge) is to distinguish between Using the word command, and Mentioning the word command. For instance, certain words perform actions, even in ordinary English, and their Use is how they do it. If you say "I do" under the proper circumstances, you might get married, for instance. But not if you're quoting what somebody else might say. Anything quoted is a Mention, not a Use.

So the first list of commands are not uses of commands; they're mentions of commands.

The second examples, like my fav

• $ rev wordlist | sort | rev > speculum
  (which produces a reverse-alphabetized copy of wordlist)

will actually do something, so they're definitely Uses.

Answer 4

I would consider there's no need to as an answer, as the ambiguity described causes no harm anyway.

In all contexts I've seen, when the word "command" refers to an executable program, it's always something an end user would type into a shell to get it running. I've never seen expressions like "the init command" or "the ld-linux.so command".

When "command" refers to a command-line program, it always actually refers to "the family of commands that begins with the said program". For example, when you say "the grep command", you're talking about all the things you can do with the grep program, which forms "a family of commands". This holds for partial commands as well, like the saying "the apt install command is for installing packages" when the full command apt install does nothing useful usually.