valkyrjaio / valkyrja-java / 30329206586

100%

push

github

[Cli] Treat a bare double dash as the end-of-options marker and a lone dash as an operand (#57)

# Description

Implements the POSIX end-of-options marker and fixes a lone `-` being
rejected.

`InputFactory` decided option-vs-operand with a bare `startsWith('-')`,
so two
conventional spellings were hard errors that took the whole command line
with
them:

```
myapp cmd -- --not-an-option   → CliInteractionInvalidNonEmptyValueException
myapp cmd -- file.txt          → CliInteractionInvalidNonEmptyValueException
myapp cmd -                    → CliInteractionInvalidNonEmptyValueException
```

`--` reached `OptionFactory`, which stripped the dashes, got an empty
name, and
threw. A bare `-` did the same.

**`--` is now the end-of-options marker.** It is consumed — it never
becomes an
operand itself — and every arg after it is an operand no matter how many
dashes
it starts with. This is how a caller passes a literal `--verbose` as
data, or a
filename that begins with a dash. A *second* `--` is therefore an
ordinary
operand, since option parsing has already ended.

**A lone `-` is now an operand.** By universal Unix convention (POSIX
Utility
Syntax Guidelines) a single dash names standard input — `cat -`, `sort
file -`,
`tar -xf -`. It is an operand, not an option. What "standard input"
means is the
command's business; the parser's job is only to stop treating it as an
option.

Positional semantics are unchanged: the command-name slot still works
exactly as
before, so a `--` spelled in that slot is consumed and the default
command name
stands (the same way an option spelled there already behaved), while a
lone `-`
in that slot fills it, because it is an operand.

Handing `--` or `-` directly to `OptionFactory` still throws — that is
correct at
that level, and those unit tests are unchanged. Only `InputFactory`,
which decides
what is an option in the first place, changed.

Found via the request/command mapping-fidelity tests, which pinned both
spellings
as cu... (continued)

1912 of 1914 branches covered (99.9%)

Branch coverage included in aggregate %.

4 of 4 new or added lines in 1 file covered. (100.0%)

6961 of 6961 relevant lines covered (100.0%)

4.34 hits per line