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

Remove the value: pass -verbose (or prefer the canonical --verbose form).

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

Error message

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

What it means

GNU getopt long-option path, the single-dash (or plus) form: when the user writes -option=value or +option=value for a no_argument long option, getopt reports the same condition as the '--' case but with the '%c%s' format (the prefix char '-' or '+' plus the name). Same root cause - a value supplied to a flag that takes none - just for the non-'--' spelling.

Source

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

	  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)
		optarg = argv[optind++];
	      else
		{
		  if (opterr)
		    fprintf (stderr,

View on GitHub (pinned to d5f144c24d)

Solutions

Remove the value: pass -verbose (or prefer the canonical --verbose form).
Verify via --help whether the option accepts an argument at all.
Standardize on the '--' long form to avoid the single-dash ambiguity.
Correct the script/template that appends =value to no-argument flags.

Example fix

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

# after
$ tool -verbose    # or preferably --verbose

Defensive patterns

Strategy: validation

Validate before calling

// Reject value attachment on single-dash no-argument long options
if (!optionHasArg(name) && attachedValue != null) {
    throw new IllegalArgumentException("Flag " + name + " takes no argument");
}

Type guard

boolean isValidSingleDashInvocation(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, or switch to the '--' form
}

Prevention

Avoid single-dash long-option spellings; use '--' to remove ambiguity.
Do not attach values to flags that take none.
Verify the option's argument policy via --help.
Correct scripts that build flags with unconditional =value suffixes.

When it happens

Trigger: Writing -longopt=value or +longopt=value (one dash or plus, attached value) for a long option defined with no_argument. getopt prints argv[0], the leading char, and the option name.

Common situations: Using a single-dash long-option spelling (some tools accept -verbose in addition to --verbose) and attaching a value; '+' prefixed options from GNU-style getopt with a stray argument; shell completion or template inserting =value onto a flag.

Related errors

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