What causes "%s: option `--%s' doesn't allow an argument" in NationalSecurityAgency/ghidra?

Drop the argument from the flag: use --quiet, not --quiet=true.

%s: option `--%s' doesn't allow an argument

Error message

%s: option `--%s' doesn't allow an argument

What it means

GNU getopt long-option path: the user wrote --option=value (or --option value) for a long option whose has_arg is 0 (no_argument). With opterr enabled, getopt prints this and returns '?'. It is a command-line usage error specific to the '--' long-option form.

Source

Thrown at GPL/DemanglerGnu/src/demangler_gnu_v2_24/c/getopt.c:711

	}

      if (pfound != NULL)
	{
	  option_index = indfound;
	  optind++;
	  if (*nameend)
	    {
	      /* Don't test has_arg with >, because some C compilers don't
		 allow it to be used on enums.  */
	      if (pfound->has_arg)
		optarg = nameend + 1;
	      else
		{
		  if (opterr)
		    {
		      if (argv[optind - 1][1] == '-')
			/* --option */
			fprintf (stderr,
				 _("%s: option `--%s' doesn't allow an argument\n"),
				 argv[0], pfound->name);
		      else
			/* +option or -option */
			fprintf (stderr,
				 _("%s: option `%c%s' doesn't allow an argument\n"),
				 argv[0], argv[optind - 1][0], pfound->name);

		      nextchar += strlen (nextchar);

		      optopt = pfound->val;
		      return '?';
		    }
		}
	    }
	  else if (pfound->has_arg == 1)
	    {
	      if (optind < argc)

View on GitHub (pinned to d5f144c24d)

Solutions

Drop the argument from the flag: use --quiet, not --quiet=true.
Check --help to confirm whether the option takes an argument.
If a value is genuinely needed, you may be using the wrong option name (find the value-accepting variant).
Fix the wrapper/template that is appending =value to no-argument flags.

Example fix

# before
$ tool --verbose=yes
... option `--verbose' doesn't allow an argument

# after - boolean flag takes no value
$ tool --verbose

Defensive patterns

Strategy: validation

Validate before calling

// Don't attach =value to known no-argument flags
boolean takesArg = optionHasArg("--" + name);  // consult the program's option spec
if (!takesArg && value != null) {
    throw new IllegalArgumentException("Flag --" + name + " takes no argument");
}

Type guard

boolean isValidInvocation(String name, String value, Set<String> noArgFlags) {
    return value == null || !noArgFlags.contains(name);
}

Try / catch

int rc = run_child({"tool", "--" + name + (value != null ? "=" + value : "")});
if (rc != 0 && stderr_contains("doesn't allow an argument")) {
    // retry without the value
}

Prevention

Consult --help to learn which flags accept arguments.
Do not append =true/=false to boolean flags.
Fix templates/wrappers that universally append =value to flags.
Prefer the canonical '--flag' spelling for boolean options.

When it happens

Trigger: Attaching a value to a flag-type long option that takes no argument, e.g. --quiet=true or --help=foo where the option is defined with no_argument. getopt detects the '=' or trailing token and reports the option cannot accept an argument.

Common situations: Assuming a boolean flag accepts =true/=false (it does not); copying a value form from a different tool whose flag does take an argument; a wrapper script that always appends '=value' to flags; mixing up a flag with a similarly-named option that does take an argument.

Related errors

AI-assisted analysis of NationalSecurityAgency/ghidra@d5f144c24d (2026-08-14). Data as JSON: /api/errors/09e5c7a796840fdd. Report an issue: GitHub.