Stop writing CLI validation. Parse it right the first time

Re:Stop writing CLI validation. Parse it right the first time by dwattttt on Saturday September 06, 2025 @11:25PM (#45155137)

> options that depend on options

What would you do for "top level option, which can be modified in two other ways"?

  (--option | --option-with-flag1 | --option-with-flag2 | --option-with-flag1-and-flag2)

would solve invalid representation, but is unwieldy.

Something that results in the usage string

  [--option [--flag1 --flag2]]

doesn't seem so bad at that point.

[ Parent | on HN ]

Re:Stop writing CLI validation. Parse it right the first time by sudahtigabulan on Sunday September 07, 2025 @12:14AM (#45155348)

I think I've seen it done like that

  --option flag1,flag2

(Maybe with another separator, as long as it doesn't need to be escaped.)

[ Parent | on HN ]

Re:Stop writing CLI validation. Parse it right the first time by dwattttt on Sunday September 07, 2025 @03:34AM (#45156175)

> --option flag1,flag2

Embedding a second parse step that the first parser doesn't deal with is done, but it's a rough compromise.

It feels like the difficulty in dealing with

  [--option [--flag1 --flag2]]

Is more to do with its expression in the language parsed to, than CLI elegance.

[ Parent | on HN ]