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

kdb delmeta command #2388

Open
kodebach opened this Issue Feb 9, 2019 · 7 comments

Comments

Projects
None yet
2 participants
@kodebach
Copy link
Contributor

kodebach commented Feb 9, 2019

Currently kdb setmeta with no argument for the value (e.g. kdb setmeta /tests/example somemeta) will remove the given metakey. This is especially problematic because Elektra uses # for the array metakey, which the shell may interpret as a comment. kdb setmeta /tests/example array #5 will remove the array metadata instead of setting it to #5.

To combat this problem, I propose we implement kdb delmeta (or kdb rmmeta to match kdb rm) for removing metakeys. kdb setmeta will then report an error if no value argument is given.

@markus2330

This comment has been minimized.

Copy link
Contributor

markus2330 commented Feb 9, 2019

Thank you for reporting the problem. We should also consider to improve the array syntax (see #182) and consistency of kdb subcommands in general (see #265).

@kodebach

This comment has been minimized.

Copy link
Contributor Author

kodebach commented Feb 9, 2019

We should also consider to improve the array syntax

Internally escaping #10 to #_10 would be nice, but it would technically be a breaking change wouldn't it?

Regarding improving kdb for array manipulation and in general: Once kdb has better support for sub-commands (using elektraGetOpts?) I think we should move to a hierarchical system would be a good idea. So kdb would for example have the subcommands array and meta, while each of those have subcommands called get, set and rm (and more), meaning kdb array set, kdb meta get and kdb array rm would all be commands.

@markus2330

This comment has been minimized.

Copy link
Contributor

markus2330 commented Feb 9, 2019

Internally escaping #10 to #_10 would be nice,

I was even thinking about escaping 10 -> #_10. Then we would get rid of the comment problem.

but it would technically be a breaking change wouldn't it?

Yes, even setmeta not removing meta data is a breaking change. Ideally we would make all these changes together in version 0.9 but this seems to be unlikely that we can fix everything correctly with one attempt. Maybe we make 0.9 an unstable branch.

Regarding improving kdb for array manipulation and in general

I moved the discussion to #265

@kodebach

This comment has been minimized.

Copy link
Contributor Author

kodebach commented Feb 9, 2019

Then we would get rid of the comment problem.

For that we could just get rid of the ' #' and keep the underscores for now, i.e. the user has to create keys named e.g. /tests/example/array/_10. But both versions are a huge change, because lots of plugins and libraries need to updated, so I would avoid that for now.

To just get rid of the comment problem, we could just add a mechanism inside of kdb setmeta that prefixes the value of the array metadata with # if it doesn't already start with #. It would technically be a breaking change, but a minor one that would only break usages that are considering wrong already, so I think we could add it to 0.8.26 (or maybe 0.8.27).

@markus2330

This comment has been minimized.

Copy link
Contributor

markus2330 commented Feb 9, 2019

To just get rid of the comment problem, we could just add a mechanism inside of kdb setmeta that prefixes the value of the array metadata with # if it doesn't already start with #.

I do not think we should provide workarounds for usability problems of the shell. If users are aware of the problem, they can easily add a \ or ''. If people are not aware, only a failure of kdb setmeta helps.

@kodebach

This comment has been minimized.

Copy link
Contributor Author

kodebach commented Feb 9, 2019

If users are aware of the problem

That is the problem, it just silently does something different than expected. A quick fix without changing behaviour would be, if kdb setmeta prints "Removing metadata xyz from key /some/key" when called with two arguments only. Alternatively it could always report which metakey was set to which value.

markus2330 added a commit that referenced this issue Feb 10, 2019

@markus2330

This comment has been minimized.

Copy link
Contributor

markus2330 commented Feb 10, 2019

You already get feedback what happened by adding -v. You can generally turn all tools to be verbose by kdb set /sw/elektra/kdb/#0/current/verbose 1 (as written in kdb(1)). UNIX tools generally do not report what they did.

But in this case, and also in situations like using another key because of cascading, it is useful to give feedback even without -v. (there is a -q to be always quiet). I followed your recommendation in f93bf36

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment