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.

  • 11
    In my experience, the ambiguity is not avoided; it is generally clear from context which meaning is intended. (I have over 30 years experience in IT.)
    – Jeff Zeitlin
    Commented Jun 24, 2021 at 19:32
  • 2
    Aren't grep, awk, bc, cut, etc, utilities? Commented Jun 24, 2021 at 19:36
  • 6
    In which situation would you expect the difference to cause harm? Examples please.
    – Jim
    Commented Jun 24, 2021 at 19:51
  • 2
    This seems like an imagined ambiguity: I thought grep was a "command" or "utility" and the rest of the line was/were "options" and "arguments" (sometimes "parameters")
    – Yorik
    Commented Jun 24, 2021 at 21:16
  • 2
    your second point contains incorrect info ... command line interface is also synonym for shell ... also refered as CLI ... command line would be what is typed into the CLI
    – jsotola
    Commented Jun 24, 2021 at 22:56

4 Answers 4


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.

  • This is mostly correct. The loose language the asker mentions happens only when speaking of input to the shell, not when calling library functions (like from libc) or syscalls (kernel traps). And yet this too is one single solitary shell command, despite not being a particular single program: status=ˋ((dd if=$device ibs=64k 2>&1 1>&3 3>&- 4>&-; echo $? >&4) | egrep -v "$dd_noise" 1>&2 3>&- 4>&-) 4>&1ˋ. Good luck counting how many separate new program images the kernel execs for that one. :)
    – tchrist
    Commented Jun 25, 2021 at 0:03
  • 1
    ls is an example of a string that is a commonly-used command, and also the name of the utility the command invokes. (Like other utilities often used with no args, like date or cal.) On most systems, /bin/ls is the executable that implements that utility. Commented Jun 25, 2021 at 6:58
  • 1
    some FTP or SFTP or WebDAV... clients also have a ls command which doesn't invoke an ls executable file (though sometimes causes a ls command to be executed on the remote server). Note that in shells where ls is or can be builtin, that builtin ls is still referred to as an utility. Commented Jun 25, 2021 at 15:11
  • 1
    google-chrome is DEFINITELY a command but I would not call it a utility
    – slebetman
    Commented Jun 25, 2021 at 15:33


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:


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.

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


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

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


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.

  • Use and abuse of (natural language) grammar is off-topic. Commented Jun 25, 2021 at 12:02
  • 1
    Sorry, but I don’t see what this has to do with the question. Consider this: What’s the longest day in the year? There are two answers: (1) the summer solstice, because it’s ~15 hours long, and (2) the day we go off daylight saving time, because it’s 25 hours long (exactly, possibly ±1 or 2 seconds) — depending on two different interpretations of the word day. “command” is analogous to “day” here. Commented Jun 25, 2021 at 19:54

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .