CLI binding for option parsing

[markus2330]

A CLI tool similar to getopt(1) with our option parsing API would be nice.

@kodebach: what do you think?

[kodebach]

How would that work?

The best solution I can think of is something like this:

source $(kdb parse-opts ni specfile.ini VAR1=/some/key/one VAR2=/some/key/two -- "$@")

It would read specfile.ini with the ni plugin and use it together with the options after -- in a call to elektraGetOpts. The output would be:

VAR1=[value of /some/key/one]
VAR2=[value of /some/key/two]

(only variables for existing keys are printed) This would be read by source and made available to your script.

However I don't see how this is any better than getopt (in fact is is probably much slower). You wouldn't really get any of the benefits of Elektra, because for that we would need to mount stuff and use plugins etc. At which point you really shouldn't be using a shell script anymore.

[markus2330]

Yes, I think the interface of getopt(1) from util-linux is okay (very similar like you suggested, your suggestion is even better actually). I only would use specification as mounted to spec, so something like:

source $(kdb parse-opts /sw/org/myapp/#0/current  --"$@")
... use the variables here

At which point you really shouldn't be using a shell script anymore.

Often you have applications and shell scripts accessing the same configuration (specification).

[kodebach]

Often you have applications and shell scripts accessing the same configuration (specification).

Okay, that make sense... I will think about doing this after to options plugin is done

[markus2330]

Actually the easiest "binding" would be something like kdb get (or it could even be kdb get but it would need some option-escaping) which also considers command-line options of the calling process.

E.g.:

# myscript.sh
RECURSIVE=`kdb oget /sw/org/myscript/#0/current/recursive  $*`

with a spec:

[recursive]
opt=r
opt/long=recursive
env=RECURSIVE

would set RECURSIVE to "1" when called like myscript.sh --recursive

The advantage would be that it would automatically also consider Elektra's configuration and not only command-line args. Obvsiously the parse-opts would also be able to do so.

[kodebach]

it could even be kdb get but it would need some option-escaping

Not a fan of that... It is not very KISS to make kdb get do that

RECURSIVE=`kdb oget /sw/org/myscript/#0/current/recursive $*`

Also not a fan of this version... That causes a lot of kdbGet calls and a the specification will be parsed every time. The only real advantage (also a disadvantage) IMHO is that it is more verbose.

[markus2330]

No, it is not very fast but it is the current way of how to get Elektra's configuration in shell scripts. I proposed here that these commands should also consider command-line opts.

Methods to do multiple get/set (like kdb shell) are not very popular afaik.

[kodebach]

This should be much easier to implement, once #3651 is merged.

[markus2330]

@hannes99 is this interesting for you?

[github-actions[bot]]

I mark this stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping by writing a message here or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart:

[github-actions[bot]]

I closed this now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart: