geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: [LONG] Daemon command line option conventions - need to agree before 1.0
Date Fri, 02 Dec 2005 00:13:28 GMT
On Dec 1, 2005, at 3:43 PM, Aaron Mulder wrote:

> I'm not a big fan of this.  I can't say why in a general way, but to
> be specific, I don't think having two options to do the same thing
> adds any value, I don't like the unintuitiveness of many of the short
> versions, I don't think --quiet is an improvement over -quiet, I don't
> think any lazy developer would ever type --veryverbose, I like
> supporting every style of "help" that a user might possibly type
> (since by definition they probably don't know the correct one, though
> I would never document all 4 like you did in your first list), and so
> on.
>
> For the new startup output, we could bring back -noprogress or try for
> something shorter like -brief or -timer.
>

I think you hit upon some things, which actually support my liking  
for the convention.

1) I also don't like the unintuitiveness of many of the short  
options, that's why the long option is great--it's descriptive.  You  
would probably hate to type it out on the command line over and over  
again and would eventually memorize the short option, but you'd be  
very considerate to use the long option in a script that others have  
to read.

2) Typically the options -a -b -c are the same as -abc.  For example

   tar -x -z -v -f myarchive.tar.gz

is the same as

   tar -xzvf myarchive.tar.gz

But you can't parse like that if you allow the long options to also  
followed by a single dash -- no way to distinguish them from a series  
of short options.

Just a couple thoughts.

-David


> Thanks,
>     Aaron
>
> On 12/1/05, John Sisson <jrsisson@gmail.com> wrote:
>> Whilst trying to come up with a name for the new command line  
>> option for
>> the Daemon for the new startup progress output (that doesn't use line
>> feeds to update the status of configurations being loaded and outputs
>> the startup time for each configuration) I chatted with David Blevins
>> and David Jencks on IRC.
>>
>> They brought to my attention that the Daemon doesn't follow the
>> convention where each option has a short form (prefixed with a single
>> dash '-') and a long form prefixed with two dashes "--".  For  
>> example,
>> run maven -h or maven --help .
>>
>> Currently the Daemon supports these options:
>>
>> -quiet
>> -v
>> -vv
>> -override
>> -h
>> -help
>> --help
>> /?
>>
>> In the list above, the -quiet, -override and -help don't fit the
>> convention I described.
>>
>> We discussed using commons CLI to process the arguments but there  
>> were
>> concerns with the size of the library and also it is getting too  
>> close
>> to 1.0 to make large changes.
>>
>> I proposed that we at least make our options follow the convention
>> discussed above (this would allow us to move to commons CLI or a
>> derivation of it in the future if needed).
>>
>> PROPOSED OPTIONS FOR 1.0 RELEASE
>>
>> -q    --quiet                  ** change impacts existing users **
>> -v    --verbose
>> -vv  --veryverbose
>> -o   --override              ** change impacts existing users **
>> -h   --help
>> -l    --long                     **  new option to change startup
>> progress format  **
>>
>> We could still have hidden support for -help and /? but I'm not  
>> sure if
>> they would work with commons CLI if we were to move to it in the  
>> future.
>>
>> In regards to the vv option being more than one character, looking at
>> the commons CLI documentation (
>> http://jakarta.apache.org/commons/cli/apidocs/org/apache/commons/ 
>> cli/Options.html
>> ), it says the short option is a single character, but it takes a  
>> string
>> argument, so I think it is more of a recommendation.  If you use more
>> than one character for the short option you lose the ability to  
>> use the
>> Option.getID() method that can be useful in switch statements.
>>
>> The deploy tool uses the long (--) form of options (doesn't support a
>> short form) but it follows the convention.
>>
>> I will send another mail regarding the startup progress and  
>> whether we
>> should change the default format.
>>
>> John
>>
>


Mime
View raw message