-
Notifications
You must be signed in to change notification settings - Fork 1
ioc cli parameters are very inconsistent #6
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
Comments
i just realized this is a resurrection of #202. |
Great idea, that would allow us to be more strict/consequent with the CLI command logic. For example
We should offload the discussion to the Wiki and see where we hit issues. |
i was thinking about the documentation, especially in the context of copy on the iocage website, which uses the word cage on the front-page. if we start from the definition of a cage is a zfs backed jail, then we should be constantly talking of cage not jail within (lib)iocage. |
Before we move this issue any further, I'd like to discuss Defining a CLI Languageto do that, i'd first like to document the commands we have right now, and group them by the Object they work on:
By ObjectThe first obvious "object" i can identify is the one that uses the commands but after that, it gets kinda hazy (for me) |
for reasons of backwards compatibility, we've made
ioc
's command line interface as inconsistent as its predecessors'.currently we have three formats, which mostly differ where the
<jail>
, that is being operated on is placed, and how it's passed.via the
--name
option:as first (and only parameter)
as first parameter of infinitely many:
as last parameter of infinitely many:
i propose standardizing on one format.
if we want to provide backwards compatibility, we should do this shims that our users can install themselves in place of the iocace_legacy (
/usr/local/sbin/iocage
) or iocage (/usr/local/bin/iocage
) binaries.The text was updated successfully, but these errors were encountered: