Flowing data in System.CommandLine

[KathleenDollard]

There are a number within the System.CommandLine flow that could potentially supply information used by later steps. From one perspective this is a core part of the process because a return code (exit code) is returned that we anticipate will be the return value of Main.

#2156 discusses what should be returned from the flow. This the broader question about what state/data should be available during execution.

Several things could supply data that could be used by later steps:

• The calling code (often static void Main(..)
• Custom parsers
• Validators (beyond the validation failure info)
• Pre-actions (non-exclusive actions in enable CliAction to be non-exclusive #2147)
• CliAction (the action of the command, previously ICommandHandler)
• Post-actions if we have them (Do we need post actions? #2161)

In the old middleware pipeline, closures could be used to stash data between the before/after next step phases, but I do not think there were other ways to share state/data.

Have you ever wished a custom parser could stash some information for use by an action? Any other variation of wanting data to pass between parts of your parser?

[KalleOlaviNiemitalo]

I have wanted a way to have interspersed options and arguments such that each option modifies, but does not entirely override, the handling of the subsequent arguments.

For example, app --encoding=Latin-9 file1.csv file2.csv --delimiter=";" file3.csv --encoding=UTF-16BE file4.csv with these semantics:

• file1.csv and file2.csv are decoded from Latin-9 and parsed using the default delimiter.
• file3.csv is decoded from Latin-9 and parsed using ";" as the delimiter.
• file4.csv is decoded from UTF16-BE and parsed using ";" as the delimiter.

I had a feature like that in one app, but it was not essential, so I was able to omit it when porting to System.CommandLine.

Somewhat similarly, in POSIX c99, the placement of -l library options between pathname operands matters.

With the current System.CommandLine API, I think this could be implemented in an application by enumerating ParseResult.Tokens and comparing them to SymbolResult.Tokens of the options and the arguments, like I do for redaction in #1795 (comment). Making CliToken.Symbol public as in #2080 would simplify that.

[tmds]

In the old middleware pipeline, closures could be used to stash data between the before/after next step phases, but I do not think there were other ways to share state/data.

I had opened an issue for supporting this through InvocationContext, similar to how ASP.NET supports this through HttpContext, see #2090.

[jonsequitur]

I have wanted a way to have interspersed options and arguments such that each option modifies, but does not entirely override, the handling of the subsequent arguments.

I believe the non-exclusive CLI actions design could accommodate this, given a context object that they can each interact with in turn.

[KalleOlaviNiemitalo]

@jonsequitur that would require the CliAction to be called for each occurrence of the option. IIRC the option argument parser is called only once per command line even if the option is repeated, so I'm surprised if the CliAction is called differently.