[jboss-as7-dev] CLI arguments convention

ssilvert at redhat.com ssilvert at redhat.com
Tue Apr 19 12:51:23 EDT 2011


The most usable command line interface I've ever seen is on the  
AS/400.  If you need help with a command, you type the command and hit  
the help key.  Then you are presented with a form showing all the  
arguments and default values.  So the help is right there where you  
need it as you fill out a form for the command.

The AS/400 has the advantage that they have full control over the  
terminal and you can easily lay out these forms when needed.  However,  
for our CLI, we could have a "prompt me" mode that prompts for each  
argument, showing default values and explanations along the way.

[localhost:9999 /] promptme deploy
local file? /foo.war
server deployable name (foo.war)? my_war_name.war
runtime name (my_war_name.war)? my_war_runtime.war
deploy to servergroup1 (yes)?
deploy to servergroup2 (yes)? no

**result: foo.war was uploaded to domain and deployed to servergroup1

[localhost:9999 /]

Quoting Alexey Loubyansky <alexey.loubyansky at redhat.com>:

>
> On 04/19/2011 04:29 PM, David M. Lloyd wrote:
>> On 04/19/2011 08:31 AM, Alexey Loubyansky wrote:
>>>
>>> In addition, it's kind of a proprietary convention. We discussed this
>>> with Max today and I'm looking into the GNU convention for command line
>>> arguments
>>
>> That is a common convention -- for command line arguments.  For
>> interactive command lines (examples I'm thinking of include 3com and
>> Cisco network management CLIs, as well as commands such as linux's "ip"
>> command which have widely variable arguments), usually it's more like:
>>
>> create-jms-cf name mycf entries foo bar baz
>
> Here is the full version
>
> [localhost:9999 /] create-jms-cf
>
> --help                            name=
> auto-group=
> entries=                          connector=
> block-on-acknowledge=
> block-on-durable-send=            block-on-non-durable-send=
> cache-large-message-client=
> call-timeout=                     client-failure-check-period=
> client-id=
> confirmation-window-size=         connection-ttl=
> consumer-max-rate=
> consumer-window-size=             discovery-group-name=
> dups-ok-batch-size=
> failover-on-initial-connection=   failover-on-server-shutdown=
> group-id=
> max-retry-interval=               min-large-message-size=
> pre-acknowledge=
> producer-max-rate=                producer-window-size=
> reconnect-attempts=
> retry-interval=                   retry-interval-multiplier=
> scheduled-thread-pool-max-size=
> thread-pool-max-size=             transaction-batch-size=
> use-global-pools=
>
>
>> Of course this falls apart for "deploy" unless you do something like this:
>>
>> deploy file mything.war as myblah.war runtime-name yourblah.war
>>
>> or something (i.e. make it somewhat more fluent and less shell-ish).
>
> Ok, so you'd actually prefer a simplicity instead of a standard convention.
> I'll think about it (and if somebody has suggestions, please, share) but
> if that doesn't work out we'll have to choose an existing convention.
>
>>> And another point is the use of '='. Some command lines don't use it, e.g.
>>>
>>> deploy --file my.war --name my_war_name.war --runtime-name
>>> my_war_runtime_name.war
>>>
>>> and some do
>>>
>>> deploy --file=my.war --name=my_war_name.war
>>> --runtime-name=my_war_runtime_name.war
>>
>> And some command lines support both :)
>
> That's too messy, IMO.
>
> Thanks,
> Alexey
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>









More information about the jboss-as7-dev mailing list