using elektraGetOpts for kdb

[markus2330]

From #4012:

It should work like git (same as commands in elektraGetOpts).

If we are interested in making it work like git, we need a patch to use elektraGetOpts for kdb. To simply assume it works like git and add options like you would in git is wrong reasoning. The current system registers options globally and requires short options, so we need to make the decisions for our current architecture. I am very for using elektraGetOpts in kdb, so I propose we adopt it.

Btw. even when we get rid of global options, we need to be careful: people will still somehow expect that the same short option behaves in similar ways (sometimes even beyond the same program suite, e.g. using -f for something other than --force will definitely be surprising for many). In the situation for avoiding the colon, we probably could simply provide only a long option.

[kodebach]

If we are interested in making it work like git, we need a patch to use elektraGetOpts for kdb.

Agreed. But we should discuss the command structure of kdb before anybody gets started on this. elektraGetOpts allows multiple levels of commands. So for example the kdb plugin-* commands could be changed into subcommands of a single kdb plugin command. This allows for shared options.

people will still somehow expect that the same short option behaves in similar ways (sometimes even beyond the same program suite, e.g. using -f for something other than --force will definitely be surprising for many)

I don't think anybody will automatically expect that the -x in kdb get -x and kdb mount -x mean the same thing, as these are very different commands. kdb get -x and kdb set -x, however, are a different story. These two are related, so some overlap of options could be expected.

I agree that -f is a very common shorthand for --force. So if --force exists or at least makes sense for the command -f shouldn't be used for something else. However, I don't think -f should be reserved for --force in general. Take a hypothetical kdb plugin-info -f for example, IMO kdb plugin-info --force doesn't make sense. What would you "(en)force" here?

In the situation for avoiding the colon, we probably could simply provide only a long option.

Definitely. Only common options should receive short options to avoid confusion.

[markus2330]

But we should discuss the command structure of kdb before anybody gets started on this. elektraGetOpts allows multiple levels of commands. So for example the kdb plugin-* commands could be changed into subcommands of a single kdb plugin command. This allows for shared options.

Yes, good point. Do you propose anything different than the current command structure in the new syntax?

Definitely. Only common options should receive short options to avoid confusion.

👍

[kodebach]

Do you propose anything different than the current command structure in the new syntax?

Mostly creating kdb plugin and kdb meta commands with subcommands for the current kdb plugin-* and kdb meta-*, but there may be more. I don't really have time to think about it right now, and I don't think this issue is particularly urgent.

[github-actions]

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 💖

[github-actions]

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 💖