Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: CLI binding for option parsing #2492

Open
markus2330 opened this Issue Mar 13, 2019 · 3 comments

Comments

Projects
None yet
2 participants
@markus2330
Copy link
Contributor

markus2330 commented Mar 13, 2019

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

@kodebach: what do you think?

@markus2330 markus2330 added the proposal label Mar 13, 2019

@kodebach

This comment has been minimized.

Copy link
Contributor

kodebach commented Mar 13, 2019

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

This comment has been minimized.

Copy link
Contributor Author

markus2330 commented Mar 13, 2019

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

This comment has been minimized.

Copy link
Contributor

kodebach commented Mar 13, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.