What you're describing is currently possible in v2 when using bash
shell. See:
http://blogs.sun.com/harsha/entry/command_line_completion_in_glassfish
This can be made possible in multimode as well but the code that detects
that <tab> key will be written in native code.
Jane
Tim Quinn wrote:
> Interesting topic.
>
> Here's another possibility - perhaps an addition to Kedar's suggestion
> rather than a replacement.
>
> How about using a completion technique the way that some/many command
> line shells do for file specs?
>
> For example:
>
> $asadmin <enter>
> $asadmin> deploy <tab>
>
> would display the first option to "deploy" that the user had not yet
> used on the command line, perhaps presented in order of
> most-frequently-used. So successive <tab> presses at that point
> might display --path, then --contextroot, then --name, and so on.
> Depending on how clever we want to get, as the user is entering the
> path value the <tab> key could do file path matching the way it does
> in shells!
>
> Taken a step further, if there is a fixed list of values for a given
> option (for instance, --virtualserver) asadmin could have retrieved
> those values from the DAS and it could display them as the choices for
> the option's values.
>
> Personally, I prefer a U/I that guides me to correct input rather than
> noting my errors - however politely it may do so - and offering me its
> guesses as to what I might have intended. Especially in command-line
> U/Is that is not always possible and so the "did you mean?" approach
> gives valuable hints when there is no effective way of constraining or
> guiding the user in the first place.
>
> - Tim
>
> Kedar Mhaswade wrote:
>
>> I see the essence of what you propose. A bit of "interactivity" when
>> software knows it's talking to a human, is probably desirable (if the
>> software
>> does not overdo it).
>>
>> Technically, it is generally possible to find out if an asadmin command
>> is being run as a part of script or not. A given command can behave
>> differently
>> based on it.
>>
>> Two possibilities emerge:
>> - Stick to rather "strict" interface when command executes as part of
>> script.
>> - Be creative and interactive when a human executes commands.
>>
>> But that gives rise to two flavors of each command and is rather
>> expensive.
>>
>> Can a reasonable compromise be made if we make a simplifying
>> assumption that
>> "multi-mode" execution of asadmin defaults to interactive use and
>> "single-mode"
>> execution follows strict interface?
>>
>> e.g.:
>> $asadmin (Enter)
>>
>> $asadmin> Enter a command or "quit": deploy
>> $asadmin> Enter the path of deployable: foo.war
>> $asadmin> Enter the context-root[foo]: bar
>> ...
>> Command "deploy" executed successfully and exited with code 0.
>> $asadmin> Enter a command or "quit": create-jdbc-connection-pool
>> $asadmin> Enter the name in the naming service (JNDI): jdbc/orapool
>> ...
>> $>asadmin>Enter a command or "quit": Quit
>>
>> The syntax for single-command is like-wise, but follows syntax and
>> accepts correctly spelled options case-insensitively.
>>
>> I always believed (as a user) that entering into multi-mode was akin
>> to declaring my consent for interaction (aka liveliness).
>>
>> Thoughts?
>>
>> - Kedar
>>
>>
>>
>> Vince Kraemer wrote:
>>
>>> This is starting to sound like the discussion that we had some time
>>> back about something similar to the 'Did you mean: x y z?" feature
>>> that Google has...
>>>
>>> See
>>> https://glassfish.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=1660.
>>>
>>>
>>> This lead to the great work that Jane did with CLI back in V2:
>>> http://blogs.sun.com/janeyoung/entry/finding_cli_commands_in_glassfish
>>>
>>> Now it is time to take the next step... What is an example of the
>>> next step... See http://userscripts.org/scripts/show/9514
>>>
>>> vbk
>>>
>>> Other notes in-line...
>>>
>>> Kedar Mhaswade wrote:
>>>
>>>>
>>>>
>>>> Jerome Dochez wrote:
>>>>
>>>>> I was talking to Jane about this yesterday, We need to ensure we
>>>>> are satisfying the CLIP requirements but that's definitely my
>>>>> feeling too,
>>>>>
>>>>> just like if someone types --contxetroot, we should interpret it
>>>>> as --contextroot...
>>>>
>>>>
>>>>
>>>> Hmm. That's interesting but difficult to get right and has
>>>> implications
>>>> on "interface" definition and compatibility.
>>>> Maybe someone did want to get an error back
>>>> on typo? (Otherwise we might have to support all the typos forever!)
>>>
>>>
>>> we might not support typos in scripts... but we want to try to make
>>> it easy for the user to keep working....
>>>
>>> Our CLI is currently like Google search, but we force the user to
>>> retype the query... instead of click the "did you mean" link....
>>>
>>> let's extend the example from jane's blog entry...
>>>
>>> USER> asadmin create-domian --adminport 4848 --user admin foo
>>>
>>> current return text>* **Closest matched command(s):
>>> create-domain*
>>> Use "help" command for a list of valid commands.
>>>
>>> proposed return text> *Closest matched command(s):
>>> create-domain*
>>> Use "help" command for a list of valid commands.
>>> Execute "asadmin create-domain --adminport 4848 --user
>>> admin foo"?
>>>
>>>
>>> If the user enters y/yes/true... the proposed command would be
>>> executed.
>>>
>>> In cases where there are multiple choices of the most likely correct
>>> choice, the Execute part of the return text would not appear.
>>>
>>> I realize that this isn't "clean" from a defined interface
>>> perspective... but, humans aren't "clean" from a defined interface
>>> perspective, either.
>>>
>>> This is the kind of feature that can delight a user when they
>>> discover it...
>>>
>>>>
>>>> Case-sensitivity is slightly different. For a long option, a "correct"
>>>> spelling in any case could be accepted as valid without huge (as in
>>>> difficult to deal with) implications.
>>>>
>>>> Incidentally, I think we need to consider the exit codes from CLI with
>>>> some seriousness. I have started a discussion topic at:
>>>> http://wiki.glassfish.java.net/Wiki.jsp?page=ProsAndConsOfAsadminExitCodes
>>>>
>>>> and will be adding content to it soon. A reasonable exit code (and
>>>> message)
>>>> would indicate the typo like: "Did you mean --contextroot instead"?
>>>> would
>>>> lead to better overall user experience.
>>>
>>>
>>> I agree. But we can go even higher then that...
>>>
>>>>
>>>> Regards,
>>>> Kedar
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>