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

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?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

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

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

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0