24

At the command line I often use "simple" commands like

mv foo/bar baz/bar

but I don't know what to call all the parts of this:

┌1┐ ┌──2───┐
git checkout master
│   └──────3──────┘
└───────4─────────┘

I (think I) know that 1 is a command and 2's an argument, and I'd probably call 3 an argument list (is that correct?).

However, I don't know what to call 4.

How are more complex "commands" labelled?

find transcripts/?.? -name '*.txt' | parallel -- sh -c 'echo $1 $2' {} {/}

I'd appreciate an answer that breaks down what to call 1,2,3,4 and what to call each part of e.g. this "command" above.

It would be great to learn also about other things that are unique/surprising that I haven't included here.

theonlygusti
  • 797
  • 5
  • 17
  • 1
    Have you looked at the `man` pages for `git` and `find`, in particular the synopsis section? – fpmurphy Jan 14 '18 at 01:55
  • 4
    *Have you looked at the man pages for git and find* So the question seems nothing to do with `git` or `find` rather general terminology for linux. – Att Righ Jan 14 '18 at 02:02
  • According to the bash man page in `A | B`, `A | B` is a **pipeline**, `A` and `B` are **commands** (it's unfortunate that this has the same name as just the first world in a command). I might call the first argument an **executable** but I can't find a source that agrees with me. – Att Righ Jan 14 '18 at 02:24
  • 4
    In the context of `git checkout ...`, `checkout` is a **subcommand**, and in the context of `sh -c ...`, `-c` is an **option**. – wjandrea Jan 14 '18 at 04:15
  • Related: [A semantics for Bash Scripts?](https://stackoverflow.com/q/23207168/418413) – kojiro Jan 14 '18 at 13:51

2 Answers2

34

The common names for each part is as follows:

┌1┐ ┌──2───┐
git checkout master
│   └──────3──────┘
└───────4─────────┘

  1. Command name (first word or token of command line that is not a redirection or variable assignment and after aliases have been expanded).

  2. Token, word, or argument to the command. From man bash:

    word: A sequence of characters considered as a single unit by the shell. Also known as a token.

  3. Generally: Arguments

  4. Command line.

The concatenation of two simple commands with a | is a pipe sequence or pipeline:

┌─1┐ ┌──────2──────┐ ┌─2─┐ ┌──2──┐   ┌──1───┐ ┌2┐┌2┐┌2┐┌────2─────┐ ┌2┐ ┌2┐
find transcripts/?.? -name '*.txt' | parallel -- sh -c 'echo $1 $2'  {} {/}
│    └────────────3──────────────┘            └────────────3──────────────┘
└───────────────────────────────────4─────────────────────────────────────┘

Mind that there are redirection and variable assignments also:

┌──5──┐ ┌1┐ ┌─2─┐ ┌─2─┐   ┌───6──┐ ┌1┐ ┌─5─┐
<infile tee file1 file2 | LC_ALL=C cat >file
└─────────7───────────┘   └───────7────────┘
└─────────────────────4────────────────────┘

Where (beside the numbers from above):

  1. redirection.
  2. Variable assignment.
  3. Simple command.

This is not an exaustive list of all the element a command line could have. Such a list is too complex for this short answer.

Community
  • 1
  • Note that the path of the command is derived from the first word there (the command name) and that word is also passed as _first_ argument to that command, it's `argv[0]`. Depending on context that _first_/_zeroth_ argument is or is not included in the list of _arguments_. – Stéphane Chazelas Jan 14 '18 at 09:48
  • 3
    In POSIX terminology, what you call _pipe_ is a _pipe sequence_ or _pipeline_ (though a pipeline can have an optional leading `!` to negate its status). _pipe_ would rather refer to the IPC mechanism used by most shells to implement pipelines (pipelines don't have to use pipes, ksh93 uses socketpairs instead on some systems for instance). Some shells have more keywords like `time`, `noglob` that can be used instead or in addition to `!` here. – Stéphane Chazelas Jan 14 '18 at 09:53
  • What about stuff like `<<<` and `<(command)` and other weird things? – theonlygusti Jan 14 '18 at 10:24
  • @StéphaneChazelas A complete list of command line idioms is just too complex to describe in the format possible on this site. –  Jan 14 '18 at 11:12
  • IMHO, these things are called *arguments* - nothing else. Redirects like `<`, `>` and `<<<` do not count as arguments, as they are not even seen as arguments by the invoked process (e.g. `argv` array in C, PHP, ...). Whether arguments are called tokens, (sub)commands etc. is tool-specific terminology (_git_ here), not shell-specific terminology. – rexkogitans Jan 14 '18 at 14:31
  • @rexkogitans The use of word or token is **very** common in shell descriptions. Please read the definition of word from man bash (a common shell). –  Jan 14 '18 at 16:49
  • 2
    **IMHO, these things are called arguments - nothing else** so I think the word token in this context means "atomic unit of bash's grammar". Here the term token only exists in the context of *shell command line*, not in the context of the program executes. It would be a bit weird to say "these are the programs tokens" but perhaps less strange to say "the second token in the command line is $test". A distinction comes up in `cat $file`, here I would say `$file` is a token, but the *value* of file is the argument. – Att Righ Jan 14 '18 at 20:44
  • @rexkogitans: If you were replying to the OP's comment, and isaac's followup, then note that **`<(command)` (process substitution) *is* an arg, as well as a redirect**. Try `echo <(true)` and you'll see `/dev/fd/63` or whatever. (The other redirect operators are not args, though. `echo <<<"text"` just prints a blank line, because `echo` doesn't read its stdin.) – Peter Cordes Jan 14 '18 at 21:45
  • 1
    @PeterCordes You are correct, <<<"…" is a redirection, not an argument. Though it is still a token of the line. Sorry for the confusion. –  Jan 14 '18 at 21:52
  • @AttRigh : Nothing else? Interesting. And I was thinking the arguments seems wrong. What I see are parameters. Parameters are information that is given away (to a program/function), while arguments are the information received (by the program/function), just as payments are simultaneously expense and income. Since programming code typically treats arguments with some variable/object, e.g. argv, and the question shows a command line, I'm inclined to call these parameters. e.g. MS-DOS has command line parameters. Though maybe Unix has different specific jargon from standardized definitions? – TOOGAM Jan 15 '18 at 05:05
  • 1
    @TOOGAM Those are exactly opposite to the standard definitions. The things the caller provides are arguments; cf. “formal parameter”, or [this SO question](https://stackoverflow.com/questions/156767/whats-the-difference-between-an-argument-and-a-parameter). – Michael Homer Jan 15 '18 at 05:30
  • Can you split parameters and arguments in your answer? ``ls -l /etc`` is a command with one parameter (``-l``) and one argument (``/etc``). – allo Jan 15 '18 at 09:31
  • 2
    @TOOGAM **"What I see are parameters"**. Hmm I think you are right. According the POSIX spec: "The shell executes a function (see Function Definition Command), built-in (see Special Built-In Utilities), executable file, or script, giving the names of the arguments as positional parameters numbered 1 to n, and the name of the command (or in the case of a function within a script, the name of the script) as the positional parameter numbered 0 (see Command Search and Execution)." and I had been wrong all these years... Although in my defense it is called `argv` – Att Righ Jan 15 '18 at 13:03
  • @allo According to shell parlance both are arguments to the command name. The command (`ls`) interprets them as an option (`-l`) and as a file (`/etc`). –  Jan 15 '18 at 14:58
  • @AttRigh **the term token only exists in the context of shell command line, not in the context of the program executes.** Yes, and the question is about the **command line terminology**. What the command name does with such parameters/arguments is entirely a business of the command name, not the shell. –  Jan 15 '18 at 15:06
16

@isaac's answer above seems good.

I want to extend this with some sources.

I guess the POSIX standard might in some sense be considered canonical. Other sources might be man bash and man proc.

┌1┐ ┌──2───┐
git checkout master
│   └──────3──────┘
└───────4─────────┘

POSIX suggests that:

  1. Is the command name (rather than the command, though even this document uses command in places)
  2. Argument
  3. Arguments
  4. Command (though man proc uses the command line)

It also has terminology for many more complicated commands.

I think command is pretty ambiguous so perhaps the term command name and command line are good for clarity.j

Att Righ
  • 1,176
  • 11
  • 29
  • What's proc? I've never heard of that. – theonlygusti Jan 14 '18 at 10:18
  • @theonlygusti http://man7.org/linux/man-pages/man5/proc.5.html – Salem Jan 14 '18 at 10:42
  • 5
    +1 I like this answer best. (In this specific context, **2** is a **subcommand**, but generally yes, an argument). – kubanczyk Jan 14 '18 at 14:02
  • @theonlygusti `proc` is a special purpose filesystem (collection of files) that provide information about the kernel's internal state. I believe it stands for *processes* (see also [sysfs](https://en.wikipedia.org/wiki/Sysfs) which provides information about things others than processes). The reason it is relevant is written by *kernel developers*, so may well reflect the language that they use which might be a little more formal. – Att Righ Jan 14 '18 at 20:28