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?


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


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.

  • libpopt erroneously printed the equals sign against short options, resulting in usage messages that were not actually the command-line syntax accepted by the program. jdebp.uk./Softwares/libpopt
    – JdeBP
    Mar 17 '20 at 13:51
  • 1
    Maybe getopt can be treated as a reference point, if not a standard so that allowing either with or without the equals sign is normal with long options; with short options, no equals sign is used.
    – Joshua Fox
    Mar 17 '20 at 14:27
  • 1
    Yes, I think it is reasonably safe to say so.
    – AdminBee
    Mar 17 '20 at 14:28
  • @JdeBP fyi, the 1st link on your libpopt page is broken
    – mosvy
    Mar 17 '20 at 15:01

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.

  • 1
    Wow, allowing options without the dash/double-dash is a mess.
    – Joshua Fox
    Mar 17 '20 at 14:29
  • @JoshuaFox: yep, it is. Ideally, you should always read manual before using a new command to know how it behaves. Mar 17 '20 at 14:30
  • 2
    I think that dd is a redherring and bringing it up is only muddling the point, as those foo=bar of dd are operands not options. There are other programs which use arguments of the key=value form (awk, make, env, etc), and they may also accept options_/switches (= command line arguments starting with a dash). Standard dd does not accept any command line _options, though GNU dd does (2 options: --help and --version).
    – mosvy
    Mar 17 '20 at 15:07
  • 1
    @mosvy: man dd from coreutils mentions both operands and options, man dd on FreeBSD uses "operand" and "option" interchangeably and I really don't understand what's the difference between operands and options - I guess that maybe GNU people used the term operand for historical compatibility as they don't start with a minus. Mar 17 '20 at 15:13
  • 1
    @ArkadiuszDrabczyk the options accepted by GNU dd are --help and --version, as already mentioned. The difference between options and other arguments/operands/etc is made by the standard, I didn't invented it ;-)
    – mosvy
    Mar 17 '20 at 15:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.