lib389

#10 Improve command line tool argument ordering
Closed: Fixed Opened by firstyear.

Closed: Fixed
Reopen Issue

Our current tools were a proof of concept, and have not got a good work flow. For example:

dsadm -Z localhost instance start

This is really horrible, and not intuitive at all. We should have a "largest to smallest" processing order. This gives us:

<command> <instance> <action> [<sub action>] <options>

For example

dsadm standalone restart
dsadm standalone remove --force
dsconf standalone uidunique enable
dsconf ldap://localhost backend create --suffix=dc=example,dc=com --name=userRoot

0001-Ticket-10-Improve-command-line-tool-arguments.patch

Metadata Update from @firstyear:
- Custom field Origin adjusted to Community
- Custom field Review Status adjusted to review

Metadata Update from @firstyear:
- Issue assigned to firstyear

I have no objections regards the issue subject. So I am happy to set 'ack' to it.

Though I have a number of issues with other tools like dsidm, dsadm. Some of them are about verbose, some usability and some bugs. Do you want me write down it here or will we move the discussion somewhere else?
Edited by spichugi

I think we should open new bugs for these issues. These are still pre-release, so they are a bit rough. I think lets get this committed, and just work on the bugs and rough edges as we see them, rather than perfecting this patch. How does that sound? I would like to see your comments about these to make them better for certain.

Sure, let's commit it and I'll create a new issue.

commit fb78d4a71a23f8a1a547356e1ab4bf9214a34c35
To ssh://git@pagure.io/lib389.git
a5a1e10..fb78d4a master -> master

Thanks mate, I look forwards to it. Appreciate your eyes on this so we can make these tools awesome.

Metadata Update from @firstyear:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
review
Community
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.