Does anybody have a script to handle script arguments?

[Oldes]

I have this code and this code in the Siskin Builder, but I think it would be nice to have some universal solution.

Any idea? Maybe @rgchris or @greggirwin have something?

[Oldes]

There is this script http://www.rebol.org/view-script.r?script=args.r but it looks quite verbose.

[greggirwin]

I did an old CLI dialect, but @hiiamboris came up with what I think is a really nice solution with his CLI approach: https://codeberg.org/hiiamboris/red-cli

It may seem large, as we're used to rolling minimal solutions, but I hope it becomes standard for Red, as it's very complete and well thought-out, including an escape hatch and sub-commands.

[Oldes]

Using a function as an entry point is quite clever.

[hiiamboris]

On size, I'd say the current code composition is about:

• 30% to reinvent things that must be a part of the standard library (including text table formatter)
• 30% to generate --help & --version so you don't have to
• 25% is for CLI state management and error reporting
• 10% to interface with function syntax
• 5% to support multi-command interfaces

I'd really myself love to throw out the runtime reinvention parts, but everything else is essential to build a no-fuss CLI general enough for the majority of use cases.

[rgchris]

I don't have anything in my scripts for this. The function idea looks interesting, otherwise I'd be tempted to turn it into Rebol values:

>> --option thing
=> [/option "thing"]

What happens when a shortcut with an argument appears before another shortcut? For example:

#"o" "--output"  "path" "Destination path to use instead of the default one"
#"q" "--quiet"   -      "Minimum output"

; called with
script.reb -oq path/to/use

; potentially expanded to
/output /quiet "path/to/use"

; or however the function is used in Boris's code

[hiiamboris]

We chose not to support anything fancy until a strong case is made for it (no one did so far ;). There are numerous approaches to CLI in the wild, all conflicting with each other (e.g. -oq path conflicts with -Ipath style). What makes sense to me is to follow Redbol philosophy throughout. How much more useful it is to have -oq argument vs. -q -o argument? It may save a few key strokes, but at the expense of lowering readability (because now you have to decipher the arguments knowing their arity by heart) and portability (because syntax like that on Windows is unheard of).

[rgchris]

I don't have a problem with any of that. I'm just curious how it resolves—after all in Redbol you can say thing/without/with arg and thing/with/without arg and both work. To what extent do you insist on compliance vs. tolerate the user doing quirky things? I guess you're suggesting not to support -oq style at all...

[greggirwin]

I think it's better to be explicit. If people complain that they can't do -lmopq ... with it, I will happily defend our stance and ask them to provide a strong argument for it, as @hiiamboris notes. I don't see a strong reason to make CLIs any more cryptic than necessary.

[hiiamboris]

I'd be tempted to turn it into Rebol values

Here's where this beautiful idea breaks apart. Let's say we see:

program --option1 --option2

Clearly, it's converted into [/option1 /option2], right?
Wrong! We don't know the syntax. option1 could be unary, then what we see is the equivalent of --option1=--option2 and the result would be [/option1 "--option2"]. Same concern applies to the -- option killswitch.

That said we could have had this intermediate form after considering the syntax. But I just didn't find any use for this intermediate form of data representation in our CLI library. Since the goal was to call a Red function, I was constructing parts of that call for a later apply use: state/call as the call path, state/operands as the block of mandatory arguments, and state/refines for the refinement-based part of that call. The apply block formed out of those three components comes closest to this idea.

E.g. if we hijack the apply: