Currently there is the limitation that args=remaining can only be for arrays (see src/libs/opts/opts.c 317).
For many applications, only one argument is needed, e.g. kdb ls.
Is it easily possible to lift this restriction? Of course, the command-line parser then should fail with an error if more than one argument is passed.
This would simplify writing the specifications for all the kdb commands for @ulrikeschaefer.
E.g. kdb ls could be like:
[help]
opt=H
opt/long=help
[...]
[path]
args = remaining
completion/shell = kdb complete
kdb complete would be called to complete the one argument of kdb ls.
@kodebach what do you think? Or is it better if we allow to refer to specific args, like args = 1 to assign the first argument to path? This might be a bigger change, though?
The args metadata was always designed to be extended. I think the best solution would be to add a new option args = single that is specified on non-array keys and expects a single remaining argument.
For a fixed number of remaining arguments assigned to different keys (like in kdb get), I need to think a bit more. I will get back to you on that...
Yes, I am fine with args = single for a single required argument. @ulrikeschaefer what do you think?
For a fixed number of arguments bigger than 1, this is the best I could come up with:
All keys that should receive one of the remaining arguments must have the metadata args = multiple. In addition they must have the metakey args/index, which defines the index of the remaining argument they receive.
If you want to make sure there are no additional remaining arguments, beyond those specified, also set args/count on the element with args/index = 0.
The indices specified by all the args/index must be consecutive and each index must only be used once.
args = single, args = remaining and args = multiple are exclusive across the whole spec. The following is invalid:
[path]
args = multiple
args/index = 0
[more/#]
args = remaining
Do you need me to implement that ASAP or is it enough for now that we have a specification?
In general we could also simply agree on a specification. For new metadata it is okay if some metadata is only implemented by one part of Elektra (e.g. autocompletion) but not by another one (gopts). But in case of extending enums (e.g. args) an implementation is preferred because valid specifications would break gopts. Maybe we meet to discuss the specification language?
As discussed, 3 variants.
This allows exactly one argument path:
[path]
args = single
This allows multiple arguments (in different spec keys) but in this spec there is only one argument to be completed and to be stored in path:
[path]
args = multiple
args/index = 0
An arbitrary number of paths is allowed (and to be completed):
[more/#]
args = remaining
Further clarifications:
To following to specs are equivalent:
[path]
args = single
behaves exactly the same as
[path]
args = multiple
args/index = 0
If args = single is used, no other args may be used in this spec. Using args = single on multiple keys is not allowed either.
Using args = multiple and args = remaining together is allowed. The args = remaining array will contain all arguments not used via args = multiple.
I will also change the current implementation, so that having multiple args = remaining is not allowed any more. This is that we can update the generated help message to add information about non-option arguments. If we have multiple args = remaining we don't know from where we should take the description. I will not update the help message now, but we have the possibility for the future.
@ulrikeschaefer can you incorparate all of this into your docu? When the command-line parser also supports this, we can move it to the tutorial.
In general it might be a good idea if the tutorial also covers code completion as ideally the code completion is something people get for free if they specify their command-line options with Elektra.