On Wed, 2018-05-23 at 11:34 +0200, Viktor Ashirov wrote:
I'd like to continue our discussion about feature parity with perl
and overall user experience of the new CLI tools.
Here are some projects where we can take inspiration for our own
* bpython interpreter
* fish shell
* Python Prompt Toolkit
(it's used to build tools like pgcli and mycli: https://github.com/
* OpenStack CLI:
Common theme is that all of these CLIs are primarily used in REPL
but they can be used in script mode as well.
Here's the quote from fish shell's design page about the law of
* Everything should be tab-completable, and every tab completion
have a description.
* Every syntax error and error in a built-in command should contain
error message describing what went wrong and a relevant help page.
Whenever possible, errors should be flagged red by the syntax
* The help manual should be easy to read, easily available from the
shell, complete and contain many examples
* The language should be uniform, so that once the user understands
command/argument syntax, they will know the whole language, and be
able to use tab-completion to discover new features.
When building these tools I took a lot of inspriation from the
openshift tools actually, but there is a logic to the design.
Everything goes from "least specific" to "most specific"
So for example,
dsctl start <instance>
This doesn't make sense because you have a "specific" action, before
the "broad concept" of an instance.
So everything is in the pattern of:
dsctl <instance> start/thing ....
dsidm <instance> user create ....
Everything goes from least specific to most.
I actually did put a lot of work into these based on design principles
already. About all we are missing is tab complete, and IIRC there is a
python argparse module for that which should work given our design.
I don't REPL mode is super important, I don't think I've EVER used a
REPL in all my years as a sysadmin because I want to be able to copy
paste out whole command sequences.
Hope that helps!
> Please let me know what do you think.
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.o
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelin
> List Archives: https://lists.fedoraproject.org/archives/list/389-deve