Command-line tooling in C

[hannes99]

Rewrite the kdb cli tool from C++ to C.

Subcommands

• [x] basename
• [ ] cache
• [x] cmerge
• [ ] complete
• [ ] convert
• [x] cp
• [x] dirname
• [ ] editor
• [ ] export
• [x] file
• [x] find
• [ ] gen
• [x] get
• [ ] global-mount/gmount
• [ ] global-umount/gumount
• [ ] list-commands
• [ ] list-tools
• [x] ls
• [ ] ~merge~
• [x] meta-[get, ls, rm, set, show]
• [ ] mount
• [x] mv
• [x] namespace
• [ ] plugin-[check, info, list]
• [ ] remount
• [x] rm
• [x] set
• [x] sget
• [ ] shell
• [ ] smount
• [ ] spec-mount/smount
• [ ] test
• [ ] umount
• [ ] validate

Related issues that should be solved in the process

• [x] #4024
• [x] #1164
• [x] #4028
• [x] #3957
• [x] #3742
• [x] #3648
• [x] #1563

[markus2330]

Thank you for creating the issues! (In particular #4432 is very good work, I see you are already diving into Elektra! :rocket:).

Some comments about the list above:

• cmerge: should be "merged" with merge so that we have only one merge command, see #3131
• Aliases should be removed (https://github.com/ElektraInitiative/libelektra/issues/3957), so in the list above " global-mount/gmount" -> only global-mount is relevant.
• for export/import we get a new library written by @atmaxinger
• for mount/umount we get a new library written by @flo91
• validate is more historical, can be dropped
• sget recommends an outdated approach, a specification with defaults should be preferred. Some command for scripts, however, would be very nice: some way to tell kdb get that command-line arguments and env variables should be interpreted via gopts.
• basename, dirname and namespace should imho be grouped, e.g. key-basename, key-dirname and key-namespace

In the list above, foundational parts are missing (the ones that do not have a command by itself). Have a look in the source folder https://master.libelektra.org/src/tools/kdb what these foundation parts could be. Without any guarantee on completeness:

• cmdline parser (we already discussed: it should be done with the gopts plugin, which probably needs improvements on the way)
• common error handling across tools (same return values, same error text etc.) A currently unused lib for error handling was done for C++ by @flo91, see https://github.com/ElektraInitiative/libelektra/tree/master/src/libs/tools/src/errors
• profiles (see kdb --help)
• bookmarks (see kdb --help)
• strategy handling, see master.libelektra.org/doc/help/elektra-merge-strategy.md (used by merge, editor, import, mount)
• ansicolors (nice coloring of output, especially for errors)
• facility to spawn subprocesses (external.cpp)
• plugindatabase.cpp (also needed by @flo91)
• specreader.cpp (might have overlap with what @flo91 does)

Coordination work can be done, as necessary, in the issues and also in the meetings all three weeks.

Btw. it would be nice if the source files are named like the command, so meta-ls.c (and not metals.c).

Btw2. have a look at https://github.com/ElektraInitiative/libelektra/issues/539. There should be some way with our gopts to do such things (I am not sure if/how POSIXLY_CORRECT is supported). Please add test more cases for kdb, including tests for command-line parsing.

Another feature we might want to solve in this reimplementation is #1610. It needs, however, first some library support. So let us keep this in the background as nice-to-have.

Then there is the question what should happen with kdb-gen which probably would be hard to rewrite and https://github.com/x86-64/mustache-c seems to be dead (last update 2019). I would suggest we make gen an extra tool (to be moved to src/tools/gen). I think this is fine as kdb gen is not used on embedded systems as it is a developer tool. So C++ should be fine. @kodebach What do you think about kdb gen?

[kodebach]

ansicolors (nice coloring of output, especially for errors)

To add to this: coloring should only happen, when outputting to a TTY (see isatty(3)).

Btw. it would be nice if the source files are named like the command, so meta-ls.c (and not metals.c).

If we go with nested commands (#539), we could also use a folder structure (e.g. meta/ls.c).

There should be some way with our gopts to do such things (I am not sure if/how POSIXLY_CORRECT is supported).

See examples/goptsCommands.c for example code. It's also explained in the docs.

As explained in the docs, when using sub-commands the position of options like -v matters and can change behaviour.

@kodebach What do you think about kdb gen?

Yeah, I don't think rewriting kdb gen as part of this makes sense. For now I'd also say put it into a separate src/tools/gen that is installed somewhere in e.g. /usr/share (not /usr/bin) and can still be invoked as kdb gen (i.e. the C code for kdb gen is just an exec to call the C++ executable if it is installed).

If we want to get rid of the C++ code in the long run, we could switch to Rust. In a quick search I found https://github.com/sunng87/handlebars-rust, which is a library for Handlebars templates (which should be mostly compatible with our Mustache templates, i.e. require little to no change in the templates). The Rust code could be put into a (self-contained) library and called via a C API. Rewriting the kdb gen code in C is probably not worth it.

[flo91]

@markus2330 Maybe the code for some subcommands can also be rewritten as part of the FLOSS course.

[markus2330]

I don't think that without the framework as basis anything can be done by someone else than @hannes99.

[markus2330]

We should add the C tooling as an alternative tool, I think we can call it ckdb.

[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: