Command Line Parameters in the Rebol Universe


#1

@giuliolunati made an interesting change recently to the %make.r process in which it would allow you to use param: value instead of param=value on the command line.

One of the motivations was auto-completion in shells. If you have your cursor _ sitting at the end of something, so r3 foob_ and hit tab, it will complete to r3 foobar.txt. But if you have r3 param=foob_ you will not get this behavior.

So breaking it up has a benefit there (as long as your command line processing doesn’t require a % on filenames, because completion in shells like bash won’t work with that).


Question #1: Do we need to support both synaxes in %make.r? I say no…we are already fighting quite a lot of complexity, and that means more code as well as more variations in documentation. Given that it is friendlier to autocomplete I suggest we adopt @giuliolunati’s method–unless anyone can think of a good reason not to.

This raises some questions, however, about things like --help. Presumably we don’t want help: yes to be how you ask for HELP. But to go with a more Rebol-like syntax, a refinement e.g. /help could be more sensible, in the same way that a: b makes more sense than a=b for assigning a parameter value.


Question #2: Beyond the special-purpose %make.r…for which we can use whatever rules are most convenient…should the interpreter itself use more of a LOAD-able syntax in general? What about best practices for Rebol command line apps?

In its own command line, Rebol already avoids using =, so it’s –do “print {Hi}” and not –do=“print {Hi}”. This isn’t done for LOAD-ability, though it similarly makes parsing a little bit easier.

Here’s some background reading on people’s ideas about best practices for command lines. Unsurprisingly, the suggestions are “be consistent with everything else”, so they advocate for supporting --help and --version, the – to end options and start formal arguments, etc.:

I don’t know about all the nuances, but as this stuff is now usermode code it offers the opportunity to experiment with different ideas.


#2

For help syntax the principle of least surprise is mandatory, so -h and --help must work. When the user has found access to help, the developer can dictate the rules.