You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by John Sisson <jr...@gmail.com> on 2005/12/02 00:26:01 UTC
[LONG] Daemon command line option conventions - need to agree before
1.0
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
Re: [LONG] Daemon command line option conventions - need to agree before 1.0
Posted by David Blevins <da...@visi.com>.
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 <jr...@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
>>
>
Re: [LONG] Daemon command line option conventions - need to agree before 1.0
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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.
Thanks,
Aaron
On 12/1/05, John Sisson <jr...@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
>
Re: [LONG] Daemon command line option conventions - need to agree before 1.0
Posted by Jason Dillon <ja...@planet57.com>.
What is the issue with using Commons CLI?
--jason
>>> 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
>>
>
Re: [LONG] Daemon command line option conventions - need to agree before 1.0
Posted by David Blevins <da...@visi.com>.
On Dec 1, 2005, at 11:36 PM, Jason Dillon wrote:
> FYI, you can implement -vv simply being the same as -v -v, the
> option will get processed twice. Add add a simple counter to track
> how many times -v was used, then once finished paring options, set
> the verbosity according the the counter. 0=terse, 1=verbose,
> 2=more-verbose, etc...
>
Exactly.
-David
> --jason
>
>
> On Dec 1, 2005, at 3:26 PM, John Sisson 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
>
Re: [LONG] Daemon command line option conventions - need to agree before 1.0
Posted by Jason Dillon <ja...@planet57.com>.
FYI, you can implement -vv simply being the same as -v -v, the option
will get processed twice. Add add a simple counter to track how many
times -v was used, then once finished paring options, set the
verbosity according the the counter. 0=terse, 1=verbose, 2=more-
verbose, etc...
--jason
On Dec 1, 2005, at 3:26 PM, John Sisson 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
Re: [LONG] Daemon command line option conventions - need to agree before 1.0
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Dec 5, 2005, at 1:10 AM, John Sisson wrote:
> Geir Magnusson Jr. wrote:
>
>>
>> On Dec 1, 2005, at 9:33 PM, John Sisson wrote:
>>
>>> OK, I now believe it was a mistake suggesting we should have a
>>> short form of *each* option.
>>
>>
>> Why? :)
>
> Why have them just for the sake of it. We would only be
> encouraging people to write cryptic scripts that are harder to
> support and harder for new users to understand. AFAIK gnu tar has
> a number of long options that don't have a short option.
They probably ran out of letters....
>
>>
>>> I agree that I wouldn't run the options together like you can
>>> with tar.
>>
>>
>> Why not?
>
>
> Because I not being a *NIX freak wouldn't think of trying to
> obfuscate my commands like that :-)
heh. It's not that hard :)
>
>>
>>>
>>> I just want to make sure we have thought this through as now is
>>> our last chance to change it before introducing migration issues
>>> for supported releases.
>>>
>>> Considering the depoy tool uses "--" for its options so we
>>> should try to be consistent, here is my final attempt, trying to
>>> follow the short (-) and long (--) convention. I actually have
>>> a habit of using the long form of options when coding commands
>>> in scripts for readability/supportability.
>>>
>>> --quiet ** changed from -quiet **
>>> -v --verbose
>>> -vv --veryverbose
>>
>>
>> For consistency...
>>
>> -V --veryverbose
>>
>> (it needs to be one char...)
>>
> I'm happy to change that if others agree.
>
> Thanks for the feedback,
>
> John
>
>>> --override ** changed from -override **
>>> -h --help
>>> --long ** new option to change startup to
>>> use long progress format **
>>>
>>> And we would support (but not actually document):
>>>
>>> -help
>>> /?
>>>
>>> John
>>>
>>> Aaron Mulder wrote:
>>>
>>>> On 12/1/05, David Blevins <da...@visi.com> wrote:
>>>>
>>>>> I didn't really mean that each option *has* to have a short
>>>>> version--
>>>>> there are only so many letters and numbers. But something
>>>>> like this...
>>>>>
>>>>
>>>> I know that many tools have established a convention. I just don't
>>>> like it for this case. I surely run tar -xzpvf and appreciate not
>>>> having to type long names for all the separate flags. But I
>>>> don't use
>>>> Geronimo with 5 flags that way. No one will combine help with
>>>> anything, many of the remaining flags covering the startup are at
>>>> least to some degree mutually exclusive, I *want* it to be
>>>> harder to
>>>> type the override flag because no one should ever use it, ...
>>>> I can't
>>>> put my finger on a single specific thing, I just don't like the
>>>> idea
>>>> as a whole. Sorry! :)
>>>>
>>>> Aaron
>>>>
>>>>
>>>>> Here are the options for some common/powerful command line tools:
>>>>>
>>>>> wget http://people.apache.org/~dblevins/cli/wget-options.txt
>>>>> tar http://people.apache.org/~dblevins/cli/tar-options.txt
>>>>> rsync http://people.apache.org/~dblevins/cli/rsync-options.txt
>>>>> patch http://people.apache.org/~dblevins/cli/patch-options.txt
>>>>> grep http://people.apache.org/~dblevins/cli/grep-options.txt
>>>>> diff http://people.apache.org/~dblevins/cli/diff-options.txt
>>>>>
>>>>>
>>>>> -D --David
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@optonline.net
Re: [LONG] Daemon command line option conventions - need to agree
before 1.0
Posted by John Sisson <jr...@gmail.com>.
Geir Magnusson Jr. wrote:
>
> On Dec 1, 2005, at 9:33 PM, John Sisson wrote:
>
>> OK, I now believe it was a mistake suggesting we should have a short
>> form of *each* option.
>
>
> Why? :)
Why have them just for the sake of it. We would only be encouraging
people to write cryptic scripts that are harder to support and harder
for new users to understand. AFAIK gnu tar has a number of long options
that don't have a short option.
>
>> I agree that I wouldn't run the options together like you can with tar.
>
>
> Why not?
Because I not being a *NIX freak wouldn't think of trying to obfuscate
my commands like that :-)
>
>>
>> I just want to make sure we have thought this through as now is our
>> last chance to change it before introducing migration issues for
>> supported releases.
>>
>> Considering the depoy tool uses "--" for its options so we should
>> try to be consistent, here is my final attempt, trying to follow the
>> short (-) and long (--) convention. I actually have a habit of
>> using the long form of options when coding commands in scripts for
>> readability/supportability.
>>
>> --quiet ** changed from -quiet **
>> -v --verbose
>> -vv --veryverbose
>
>
> For consistency...
>
> -V --veryverbose
>
> (it needs to be one char...)
>
I'm happy to change that if others agree.
Thanks for the feedback,
John
>> --override ** changed from -override **
>> -h --help
>> --long ** new option to change startup to use
>> long progress format **
>>
>> And we would support (but not actually document):
>>
>> -help
>> /?
>>
>> John
>>
>> Aaron Mulder wrote:
>>
>>> On 12/1/05, David Blevins <da...@visi.com> wrote:
>>>
>>>> I didn't really mean that each option *has* to have a short version--
>>>> there are only so many letters and numbers. But something like
>>>> this...
>>>>
>>>
>>> I know that many tools have established a convention. I just don't
>>> like it for this case. I surely run tar -xzpvf and appreciate not
>>> having to type long names for all the separate flags. But I don't use
>>> Geronimo with 5 flags that way. No one will combine help with
>>> anything, many of the remaining flags covering the startup are at
>>> least to some degree mutually exclusive, I *want* it to be harder to
>>> type the override flag because no one should ever use it, ... I can't
>>> put my finger on a single specific thing, I just don't like the idea
>>> as a whole. Sorry! :)
>>>
>>> Aaron
>>>
>>>
>>>> Here are the options for some common/powerful command line tools:
>>>>
>>>> wget http://people.apache.org/~dblevins/cli/wget-options.txt
>>>> tar http://people.apache.org/~dblevins/cli/tar-options.txt
>>>> rsync http://people.apache.org/~dblevins/cli/rsync-options.txt
>>>> patch http://people.apache.org/~dblevins/cli/patch-options.txt
>>>> grep http://people.apache.org/~dblevins/cli/grep-options.txt
>>>> diff http://people.apache.org/~dblevins/cli/diff-options.txt
>>>>
>>>>
>>>> -D --David
>>>>
>>>>
>>>>
>>>
>>>
>>
>
Re: [LONG] Daemon command line option conventions - need to agree before 1.0
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 12/4/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> For consistency...
>
> -V --veryverbose
>
> (it needs to be one char...)
Why? -vv is fine.
Aaron
Re: [LONG] Daemon command line option conventions - need to agree
before 1.0
Posted by John Sisson <jr...@gmail.com>.
Matt,
This has already been closed in
http://issues.apache.org/jira/browse/GERONIMO-1269 .
No one backed up Geir's suggestion to use one char so we will leave it
as is (see JIRA for details).
John
Matt Hogstrom wrote:
>om> <63...@optonline.net>
>In-Reply-To: <63...@optonline.net>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>Content-Transfer-Encoding: 7bit
>X-MMS-Smtp-Program: Macallan-Mail-Solution; Version 4.6.0.1
>X-MMS-Smtp-Auth: Authenticated As matt@hogstrom.org
>X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version 4.6.0.1
>
>To help close this issue out is there a proposed solution for getting this
>completed today or tomorrow and who is the point person?
>
>Cheers.
>
>Matt
>
>Geir Magnusson Jr. wrote:
>
>
>>On Dec 5, 2005, at 1:10 AM, John Sisson wrote:
>>
>>
>>
>>>Geir Magnusson Jr. wrote:
>>>
>>>
>>>
>>>>On Dec 1, 2005, at 9:33 PM, John Sisson wrote:
>>>>
>>>>
>>>>
>>>>>OK, I now believe it was a mistake suggesting we should have a
>>>>>short form of *each* option.
>>>>>
>>>>>
>>>>
>>>>Why? :)
>>>>
>>>>
>>>Why have them just for the sake of it. We would only be encouraging
>>>people to write cryptic scripts that are harder to support and harder
>>>for new users to understand. AFAIK gnu tar has a number of long
>>>options that don't have a short option.
>>>
>>>
>>They probably ran out of letters....
>>
>>
>>
>>>>>I agree that I wouldn't run the options together like you can with
>>>>>tar.
>>>>>
>>>>>
>>>>
>>>>Why not?
>>>>
>>>>
>>>
>>>Because I not being a *NIX freak wouldn't think of trying to
>>>obfuscate my commands like that :-)
>>>
>>>
>>heh. It's not that hard :)
>>
>>
>>
>>
>>>>>I just want to make sure we have thought this through as now is
>>>>>our last chance to change it before introducing migration issues
>>>>>for supported releases.
>>>>>
>>>>>Considering the depoy tool uses "--" for its options so we should
>>>>>try to be consistent, here is my final attempt, trying to follow
>>>>>the short (-) and long (--) convention. I actually have a habit
>>>>>of using the long form of options when coding commands in scripts
>>>>>for readability/supportability.
>>>>>
>>>>> --quiet ** changed from -quiet **
>>>>>-v --verbose
>>>>>-vv --veryverbose
>>>>>
>>>>>
>>>>
>>>>For consistency...
>>>>
>>>>-V --veryverbose
>>>>
>>>>(it needs to be one char...)
>>>>
>>>>
>>>>
>>>I'm happy to change that if others agree.
>>>
>>>Thanks for the feedback,
>>>
>>>John
>>>
>>>
>>>
>>>>> --override ** changed from -override **
>>>>>-h --help
>>>>> --long ** new option to change startup to use
>>>>>long progress format **
>>>>>
>>>>>And we would support (but not actually document):
>>>>>
>>>>>-help
>>>>>/?
>>>>>
>>>>>John
>>>>>
>>>>>Aaron Mulder wrote:
>>>>>
>>>>>
>>>>>
>>>>>>On 12/1/05, David Blevins <da...@visi.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I didn't really mean that each option *has* to have a short
>>>>>>>version--
>>>>>>>there are only so many letters and numbers. But something like
>>>>>>>this...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>I know that many tools have established a convention. I just don't
>>>>>>like it for this case. I surely run tar -xzpvf and appreciate not
>>>>>>having to type long names for all the separate flags. But I
>>>>>>don't use
>>>>>>Geronimo with 5 flags that way. No one will combine help with
>>>>>>anything, many of the remaining flags covering the startup are at
>>>>>>least to some degree mutually exclusive, I *want* it to be harder to
>>>>>>type the override flag because no one should ever use it, ... I
>>>>>>can't
>>>>>>put my finger on a single specific thing, I just don't like the idea
>>>>>>as a whole. Sorry! :)
>>>>>>
>>>>>>Aaron
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Here are the options for some common/powerful command line tools:
>>>>>>>
>>>>>>> wget http://people.apache.org/~dblevins/cli/wget-options.txt
>>>>>>> tar http://people.apache.org/~dblevins/cli/tar-options.txt
>>>>>>> rsync http://people.apache.org/~dblevins/cli/rsync-options.txt
>>>>>>> patch http://people.apache.org/~dblevins/cli/patch-options.txt
>>>>>>> grep http://people.apache.org/~dblevins/cli/grep-options.txt
>>>>>>> diff http://people.apache.org/~dblevins/cli/diff-options.txt
>>>>>>>
>>>>>>>
>>>>>>>-D --David
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>
>
>
>
Re: [LONG] Daemon command line option conventions - need to agree
before 1.0
Posted by Matt Hogstrom <ma...@hogstrom.org>.
om> <63...@optonline.net>
In-Reply-To: <63...@optonline.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MMS-Smtp-Program: Macallan-Mail-Solution; Version 4.6.0.1
X-MMS-Smtp-Auth: Authenticated As matt@hogstrom.org
X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version 4.6.0.1
To help close this issue out is there a proposed solution for getting this
completed today or tomorrow and who is the point person?
Cheers.
Matt
Geir Magnusson Jr. wrote:
>
> On Dec 5, 2005, at 1:10 AM, John Sisson wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>>
>>> On Dec 1, 2005, at 9:33 PM, John Sisson wrote:
>>>
>>>> OK, I now believe it was a mistake suggesting we should have a
>>>> short form of *each* option.
>>>
>>>
>>>
>>> Why? :)
>>
>>
>> Why have them just for the sake of it. We would only be encouraging
>> people to write cryptic scripts that are harder to support and harder
>> for new users to understand. AFAIK gnu tar has a number of long
>> options that don't have a short option.
>
>
> They probably ran out of letters....
>
>>
>>>
>>>> I agree that I wouldn't run the options together like you can with
>>>> tar.
>>>
>>>
>>>
>>> Why not?
>>
>>
>>
>> Because I not being a *NIX freak wouldn't think of trying to
>> obfuscate my commands like that :-)
>
>
> heh. It's not that hard :)
>
>
>>
>>>
>>>>
>>>> I just want to make sure we have thought this through as now is
>>>> our last chance to change it before introducing migration issues
>>>> for supported releases.
>>>>
>>>> Considering the depoy tool uses "--" for its options so we should
>>>> try to be consistent, here is my final attempt, trying to follow
>>>> the short (-) and long (--) convention. I actually have a habit
>>>> of using the long form of options when coding commands in scripts
>>>> for readability/supportability.
>>>>
>>>> --quiet ** changed from -quiet **
>>>> -v --verbose
>>>> -vv --veryverbose
>>>
>>>
>>>
>>> For consistency...
>>>
>>> -V --veryverbose
>>>
>>> (it needs to be one char...)
>>>
>> I'm happy to change that if others agree.
>>
>> Thanks for the feedback,
>>
>> John
>>
>>>> --override ** changed from -override **
>>>> -h --help
>>>> --long ** new option to change startup to use
>>>> long progress format **
>>>>
>>>> And we would support (but not actually document):
>>>>
>>>> -help
>>>> /?
>>>>
>>>> John
>>>>
>>>> Aaron Mulder wrote:
>>>>
>>>>> On 12/1/05, David Blevins <da...@visi.com> wrote:
>>>>>
>>>>>> I didn't really mean that each option *has* to have a short
>>>>>> version--
>>>>>> there are only so many letters and numbers. But something like
>>>>>> this...
>>>>>>
>>>>>
>>>>> I know that many tools have established a convention. I just don't
>>>>> like it for this case. I surely run tar -xzpvf and appreciate not
>>>>> having to type long names for all the separate flags. But I
>>>>> don't use
>>>>> Geronimo with 5 flags that way. No one will combine help with
>>>>> anything, many of the remaining flags covering the startup are at
>>>>> least to some degree mutually exclusive, I *want* it to be harder to
>>>>> type the override flag because no one should ever use it, ... I
>>>>> can't
>>>>> put my finger on a single specific thing, I just don't like the idea
>>>>> as a whole. Sorry! :)
>>>>>
>>>>> Aaron
>>>>>
>>>>>
>>>>>> Here are the options for some common/powerful command line tools:
>>>>>>
>>>>>> wget http://people.apache.org/~dblevins/cli/wget-options.txt
>>>>>> tar http://people.apache.org/~dblevins/cli/tar-options.txt
>>>>>> rsync http://people.apache.org/~dblevins/cli/rsync-options.txt
>>>>>> patch http://people.apache.org/~dblevins/cli/patch-options.txt
>>>>>> grep http://people.apache.org/~dblevins/cli/grep-options.txt
>>>>>> diff http://people.apache.org/~dblevins/cli/diff-options.txt
>>>>>>
>>>>>>
>>>>>> -D --David
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [LONG] Daemon command line option conventions - need to agree before 1.0
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Dec 1, 2005, at 9:33 PM, John Sisson wrote:
> OK, I now believe it was a mistake suggesting we should have a
> short form of *each* option.
Why? :)
> I agree that I wouldn't run the options together like you can with
> tar.
Why not?
>
> I just want to make sure we have thought this through as now is our
> last chance to change it before introducing migration issues for
> supported releases.
>
> Considering the depoy tool uses "--" for its options so we should
> try to be consistent, here is my final attempt, trying to follow
> the short (-) and long (--) convention. I actually have a habit of
> using the long form of options when coding commands in scripts for
> readability/supportability.
>
> --quiet ** changed from -quiet **
> -v --verbose
> -vv --veryverbose
For consistency...
-V --veryverbose
(it needs to be one char...)
> --override ** changed from -override **
> -h --help
> --long ** new option to change startup to use
> long progress format **
>
> And we would support (but not actually document):
>
> -help
> /?
>
> John
>
> Aaron Mulder wrote:
>
>> On 12/1/05, David Blevins <da...@visi.com> wrote:
>>
>>> I didn't really mean that each option *has* to have a short
>>> version--
>>> there are only so many letters and numbers. But something like
>>> this...
>>>
>>
>> I know that many tools have established a convention. I just don't
>> like it for this case. I surely run tar -xzpvf and appreciate not
>> having to type long names for all the separate flags. But I don't
>> use
>> Geronimo with 5 flags that way. No one will combine help with
>> anything, many of the remaining flags covering the startup are at
>> least to some degree mutually exclusive, I *want* it to be harder to
>> type the override flag because no one should ever use it, ... I
>> can't
>> put my finger on a single specific thing, I just don't like the idea
>> as a whole. Sorry! :)
>>
>> Aaron
>>
>>
>>> Here are the options for some common/powerful command line tools:
>>>
>>> wget http://people.apache.org/~dblevins/cli/wget-options.txt
>>> tar http://people.apache.org/~dblevins/cli/tar-options.txt
>>> rsync http://people.apache.org/~dblevins/cli/rsync-options.txt
>>> patch http://people.apache.org/~dblevins/cli/patch-options.txt
>>> grep http://people.apache.org/~dblevins/cli/grep-options.txt
>>> diff http://people.apache.org/~dblevins/cli/diff-options.txt
>>>
>>>
>>> -D --David
>>>
>>>
>>>
>>
>>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [LONG] Daemon command line option conventions - need to agree before 1.0
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I like that more.
Thanks,
Aaron
On 12/1/05, John Sisson <jr...@gmail.com> wrote:
> OK, I now believe it was a mistake suggesting we should have a short
> form of *each* option. I agree that I wouldn't run the options together
> like you can with tar.
>
> I just want to make sure we have thought this through as now is our last
> chance to change it before introducing migration issues for supported
> releases.
>
> Considering the depoy tool uses "--" for its options so we should try to
> be consistent, here is my final attempt, trying to follow the short (-)
> and long (--) convention. I actually have a habit of using the long
> form of options when coding commands in scripts for
> readability/supportability.
>
> --quiet ** changed from -quiet **
> -v --verbose
> -vv --veryverbose
> --override ** changed from -override **
> -h --help
> --long ** new option to change startup to use long progress format **
>
> And we would support (but not actually document):
>
> -help
> /?
>
> John
>
> Aaron Mulder wrote:
>
> >On 12/1/05, David Blevins <da...@visi.com> wrote:
> >
> >
> >>I didn't really mean that each option *has* to have a short version--
> >>there are only so many letters and numbers. But something like this...
> >>
> >>
> >
> >I know that many tools have established a convention. I just don't
> >like it for this case. I surely run tar -xzpvf and appreciate not
> >having to type long names for all the separate flags. But I don't use
> >Geronimo with 5 flags that way. No one will combine help with
> >anything, many of the remaining flags covering the startup are at
> >least to some degree mutually exclusive, I *want* it to be harder to
> >type the override flag because no one should ever use it, ... I can't
> >put my finger on a single specific thing, I just don't like the idea
> >as a whole. Sorry! :)
> >
> >Aaron
> >
> >
> >
> >>Here are the options for some common/powerful command line tools:
> >>
> >> wget http://people.apache.org/~dblevins/cli/wget-options.txt
> >> tar http://people.apache.org/~dblevins/cli/tar-options.txt
> >> rsync http://people.apache.org/~dblevins/cli/rsync-options.txt
> >> patch http://people.apache.org/~dblevins/cli/patch-options.txt
> >> grep http://people.apache.org/~dblevins/cli/grep-options.txt
> >> diff http://people.apache.org/~dblevins/cli/diff-options.txt
> >>
> >>
> >>-D --David
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
Re: [LONG] Daemon command line option conventions - need to agree
before 1.0
Posted by John Sisson <jr...@gmail.com>.
OK, I now believe it was a mistake suggesting we should have a short
form of *each* option. I agree that I wouldn't run the options together
like you can with tar.
I just want to make sure we have thought this through as now is our last
chance to change it before introducing migration issues for supported
releases.
Considering the depoy tool uses "--" for its options so we should try to
be consistent, here is my final attempt, trying to follow the short (-)
and long (--) convention. I actually have a habit of using the long
form of options when coding commands in scripts for
readability/supportability.
--quiet ** changed from -quiet **
-v --verbose
-vv --veryverbose
--override ** changed from -override **
-h --help
--long ** new option to change startup to use long progress format **
And we would support (but not actually document):
-help
/?
John
Aaron Mulder wrote:
>On 12/1/05, David Blevins <da...@visi.com> wrote:
>
>
>>I didn't really mean that each option *has* to have a short version--
>>there are only so many letters and numbers. But something like this...
>>
>>
>
>I know that many tools have established a convention. I just don't
>like it for this case. I surely run tar -xzpvf and appreciate not
>having to type long names for all the separate flags. But I don't use
>Geronimo with 5 flags that way. No one will combine help with
>anything, many of the remaining flags covering the startup are at
>least to some degree mutually exclusive, I *want* it to be harder to
>type the override flag because no one should ever use it, ... I can't
>put my finger on a single specific thing, I just don't like the idea
>as a whole. Sorry! :)
>
>Aaron
>
>
>
>>Here are the options for some common/powerful command line tools:
>>
>> wget http://people.apache.org/~dblevins/cli/wget-options.txt
>> tar http://people.apache.org/~dblevins/cli/tar-options.txt
>> rsync http://people.apache.org/~dblevins/cli/rsync-options.txt
>> patch http://people.apache.org/~dblevins/cli/patch-options.txt
>> grep http://people.apache.org/~dblevins/cli/grep-options.txt
>> diff http://people.apache.org/~dblevins/cli/diff-options.txt
>>
>>
>>-D --David
>>
>>
>>
>>
>
>
>
Re: [LONG] Daemon command line option conventions - need to agree before 1.0
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 12/1/05, David Blevins <da...@visi.com> wrote:
> I didn't really mean that each option *has* to have a short version--
> there are only so many letters and numbers. But something like this...
I know that many tools have established a convention. I just don't
like it for this case. I surely run tar -xzpvf and appreciate not
having to type long names for all the separate flags. But I don't use
Geronimo with 5 flags that way. No one will combine help with
anything, many of the remaining flags covering the startup are at
least to some degree mutually exclusive, I *want* it to be harder to
type the override flag because no one should ever use it, ... I can't
put my finger on a single specific thing, I just don't like the idea
as a whole. Sorry! :)
Aaron
> Here are the options for some common/powerful command line tools:
>
> wget http://people.apache.org/~dblevins/cli/wget-options.txt
> tar http://people.apache.org/~dblevins/cli/tar-options.txt
> rsync http://people.apache.org/~dblevins/cli/rsync-options.txt
> patch http://people.apache.org/~dblevins/cli/patch-options.txt
> grep http://people.apache.org/~dblevins/cli/grep-options.txt
> diff http://people.apache.org/~dblevins/cli/diff-options.txt
>
>
> -D --David
>
>
Re: [LONG] Daemon command line option conventions - need to agree before 1.0
Posted by David Blevins <da...@visi.com>.
On Dec 1, 2005, at 3:26 PM, John Sisson 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 .
I didn't really mean that each option *has* to have a short version--
there are only so many letters and numbers. But something like this...
Here are the options for some common/powerful command line tools:
wget http://people.apache.org/~dblevins/cli/wget-options.txt
tar http://people.apache.org/~dblevins/cli/tar-options.txt
rsync http://people.apache.org/~dblevins/cli/rsync-options.txt
patch http://people.apache.org/~dblevins/cli/patch-options.txt
grep http://people.apache.org/~dblevins/cli/grep-options.txt
diff http://people.apache.org/~dblevins/cli/diff-options.txt
-D --David