Do command line options take an equals sign between option name and value?

Question

Just using kubectl as an example, I note that

kubectl run --image nginx ...

and

kubectl run --image=nginx ...

both work.

For command-line programs in general, is there a rule about whether an equals sign is allowed/required between the option name and the value?

Answer 1

In general, the implementation of how command-line arguments are interpreted is left completely at the discretion of the programmer.

That said, in many cases, the value of a "long" option (such as is introduced with --option_name) is specified with an = between the option name and the value (i.e. --option_name=value), whereas for single-letter options it is more customary to separate the flag and value with a space, such as -o value, or use no separation at all (as in -oValue).

An example from the man-page of the GNU date utility:

  -d, --date=STRING
        display time described by STRING, not 'now'

  -f, --file=DATEFILE
        like --date; once for each line of DATEFILE

As you can see, the value would be separated by a space from the option switch when using the "short" form (i.e. -d), but by an = when using the "long" form (i.e. --date).

Edit

As pointed out by Stephen Kitt, the GNU coding standard recommends the use of getopt and getopt_long to parse command-line options. The man-page of getopt_long states:

A long option may take a parameter, of the form --arg=param or --arg param.

So, a program using that function will accept both forms.

Answer 2

For command-line programs in general, is there a rule about whether an equals sign is allowed/required between the switch and the value?

No, there isn't. There are many competing standards in the open source world and computing in general (obligatory xkcd) and everyone can come up with new rules and standards any time they want. POSIX Utility Argument Syntax for example doesn't mention = at all for example while man getopt mentions it. In practice you can come across all kinds of command line programs:

Those that take long option value after = or after a whitespace:

$ touch a b c d
$ ls --format=verbose
total 0
-rw-r--r-- 1 ja users 0 Mar 17 14:39 a
-rw-r--r-- 1 ja users 0 Mar 17 14:39 b
-rw-r--r-- 1 ja users 0 Mar 17 14:39 c
-rw-r--r-- 1 ja users 0 Mar 17 14:39 d
$ ls --format verbose
total 0
-rw-r--r-- 1 ja users 0 Mar 17 14:39 a
-rw-r--r-- 1 ja users 0 Mar 17 14:39 b
-rw-r--r-- 1 ja users 0 Mar 17 14:39 c
-rw-r--r-- 1 ja users 0 Mar 17 14:39 d

Those that do not take long option value after = but require a whitespace:

$ readelf  -a main | grep  'program interpreter'
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
$ patchelf --set-interpreter=fake main
patchelf: getting info about '--set-interpreter=fake': No such file or directory
$ patchelf --set-interpreter fake main
$ readelf  -a main | grep  'program interpreter'
      [Requesting program interpreter: fake]

Those that take value after = but do not take options with - or --:

dd if=/dev/urandom of=~/Desktop/test.txt bs=1M count=3

There can be many reasons for a which a given command line program accepts input in a given way: author's vision, because nobody cares, because author didn't know that someone else has already come up with a standard, because program has been ported onto Unix from different operating system with completely different conventions or has been made to look like it has been.