1 Answers1

3

tl;dr summary: none of these terms have a universal definition.

  • application: the term is not universally well-defined, its definition depends on the context, the community, sometimes even the person using it.
  • program: the term is not universally well-defined, its definition depends on the context, the community, sometimes even the person using it.
  • process: the term is not universally well-defined, its definition depends on the context, the community, sometimes even the person using it.
  • job: the term is not universally well-defined, its definition depends on the context, the community, sometimes even the person using it.
  • task: the term is not universally well-defined, its definition depends on the context, the community, sometimes even the person using it.
  • service: the term is not universally well-defined, its definition depends on the context, the community, sometimes even the person using it.
  • daemon: the term is not universally well-defined, its definition depends on the context, the community, sometimes even the person using it.
  • script: the term is not universally well-defined, its definition depends on the context, the community, sometimes even the person using it.
  • command: the term is not universally well-defined, its definition depends on the context, the community, sometimes even the person using it.

(I think you are starting to see the pattern here.)

In all of these cases, you will have to ask the person using the term to define it. The only person that can tell you how a particular person uses that term is that particular person.

If you are reading an official standards document, the terms used in that standard will often be explicitly defined, in which case only within this specific standards document, the terms mean exactly what the standards document says they mean.

Let's just as an example look at only one of the terms, the term command, and let's further restrict ourselves only to the Single Unix Specification version 4, 2018 Edition, Volumes XBD (Base Definitions) and XCU (Shell & Utilities).

In XBD Chapter 3 Definitions, Clause 3.104 Commands, the term Command is defined like this:

3.104 Command

A directive to the shell to perform a particular task.

Note:

Shell Commands are defined in detail in XCU Shell Commands.

(By the way, notice how the definition itself uses the term task, which is also one of the terms you asked about, but which is not actually defined in the SUSv4.)

So, the SUSv4 seems to define the term command as "a directive to the shell to perform a particular task". And there is also a link to a more detailed definition in XCU Chapter 2 Shell Command Language, Clause 2.9 Shell Commands:

2.9 Shell Commands

[…]

A command is one of the following:

  • Simple command (see Simple Commands)
  • Pipeline (see Pipelines)
  • List compound-list (see Lists)
  • Compound command (see Compound Commands)
  • Function definition (see Function Definition Command)

[…]

And it goes on further to define each one of those in 2.9.1 Simple Commands, 2.9.2 Pipelines, 2.9.3 Lists, 2.9.4 Compound commands, and 2.9.5 Function definition command.

Great, so, does this mean that we now know what a command is? Well, not quite, because if we read the specification of the ed utility in XCU Chapter 4 Utilities, we find that this uses the term command in a different way:

DESCRIPTION

The ed utility is a line-oriented text editor that uses two modes: command mode and input mode. In command mode the input characters shall be interpreted as commands, and in input mode they shall be interpreted as text. See the EXTENDED DESCRIPTION section.

[…]

EXTENDED DESCRIPTION

The ed utility shall operate on a copy of the file it is editing; changes made to the copy shall have no effect on the file until a w (write) command is given. The copy of the text is called the buffer.

Commands to ed have a simple and regular structure: zero, one, or two addresses followed by a single-character command, possibly followed by parameters to that command. These addresses specify one or more lines in the buffer. Every command that requires addresses has default addresses, so that the addresses very often can be omitted. If the -p option is specified, the prompt string shall be written to standard output before each command is read.

And then it goes on to further define the structure of commands, and the various commands that exist.

So, even within the same specification, we already have found two different definitions of the term command. One is given explicitly as "A directive to the shell to perform a particular task." and the other is given implicitly as "A directive to the ed utility to perform a particular task."

But it gets even more interesting. If we look at the specification of the awk utility, we find that, just like the shell, and just like the ed utility, we can supply "a directive to performa a particular task", so we might assume that this is also called a command. However, that is not the case:

DESCRIPTION

The awk utility shall execute programs written in the awk programming language, which is specialized for textual data manipulation. […]

So, the same concept that is called a command in ed is called a program in awk. Which is coincidentally another term that you asked about, but probably not the definition you thought it would have!

In the find utility, we again have a similar concept, but here it is neither called a command nor a program, but an expression made up of primaries and operators.

And in the pax utility, we again have "a thing that tells the utility what to do", but here it is called the mode, which is however a completely different thing from what the chmod utility calls a mode.

As you can see, even if we restrict ourselves to only a very narrow context (only the Single Unix Specification version 4, 2018 Edition, and in fact only two out of the four volumes) and only a single one of those terms, we can already find multiple different concepts described by that same term, as well as different terms to describe the same concept (or very similar, closely related concepts).

Jörg W Mittag
  • 3,690