Also, getting rid of leading spaces when entering a command before parsing it, e.g.:
[/] connect
Unexpected command ' connect'. Type 'help' for the list of supported
commands.
[/]connect #works
[/] :add-system-property(name=foo,value=bar)
Unexpected command ' :add-system-property(name=foo,value=bar) '. Type
'help' for the list of supported commands.
On 14 Mar 2011, at 11:10, Darran Lofthouse wrote:
On 03/14/2011 11:02 AM, Kabir Khan wrote:
> A nice feature would be some history between cli sessions
> On 9 Mar 2011, at 12:35, Dimitris Andreadis wrote:
+1 - when I was using it the other day the first thing I tried was pressing the up arrow
to get the commands from my last session.
>
>> +1, Max's suggestion make sense to me.
>>
>> On 07/03/2011 19:03, Max Rydahl Andersen wrote:
>>>>>> Max, Emanuel and I discussed the usability aspects of the cli
today. We
>>>>>> agreed on the following:
>>>>>>
>>>>>> 1) drop the '/' prefix for the commands;
>>>>>>
>>>>
>>>> How does this relate to the discussion of low-level commands vs high
level?
>>>
>>> It was a long discussion - but let me see if I can summarize what drove
this.
>>>
>>> There are some subjectivity in parts of this but mostly its driven by not
making the
>>> shell being "weird" compared to what users otherwise sees in the
wild...thus / is suggested as a separator to match filesystem and url paths.
>>>
>>> When starting up the cli it also just feels so weird and wrong to require
typing / to get to a command
>>> (unless of course you are an IRC guy - but thats not really the audience we
cater to is it ?:)
>>>
>>> Thus my suggestion was to make the logic so if you just type a string, i.e.
"help"
>>> then it will mean "execute the command or alias named help" nothing
else. Just like a normal shell.
>>>
>>> If you want to "execute" something in the current node/path you
need to (just like in a bash/zsh etc. without a PATH setup)
>>> to put ./<path>:<operation> to execute it.
>>>
>>> so the suggested syntax allow you to type things like:
>>>
>>> jboss-admin.sh
>>> $ connect
>>> [/] # default connect is root.
>>> $ cn subsystem=web
>>> [/subsystem=web]
>>> $ :read-resource-configuration #executing operation against current node.
>>> $ ..:read-resource-configuration # executing against parent node (not sure if
this should actually be ../:read-resource-configuration?)
>>>
>>> $ cn ../hosts=undefined/server=server1 # up one level and into the path.
>>> [/hosts=undefined/server=server1]
>>> $ /subsystem=web:read-resource-configuration # execute based on root ignoring
the current node
>>> [/hosts=undefined/server=server1]
>>> $ rr # a command/alias that will execute :read-reosource-configuration
>>> <return the result>
>>>
>>> We even discussed if it should be legal to do:
>>> [/hosts=undefined/server=server1]
>>> $ =server2:read-resource-configuration # execute the operation in context
of current nodetype, but change the name vs requiring eplicit typing.
>>>
>>> $../server=server2:read-resource-configuration
>>>
>>> With this tab completion still can know if it should be completing names,
children or operations AND we get a "navigational" syntax that mimicks well
known paths.
>>>
>>> We could even go all the way and allowed / instead of = you could actually
copy the paths directly between your curl/browser and the cli - only diff would be the
operation syntax.
>>>
>>> Hope that gave some more context - at least with these changes the CLI
navigation doesn't feel so alien to newbies...their brains can spend more
>>> energy to actually understand the semantics of the operations than the
syntax.
>>>
>>> /max
>>>
>>>>
>>>> Other than that question, what you describe here sounds fine (including
>>>> the 'cd' alias, which I know would be what I'd naturally
use).
>>>
>>>
>>>>
>>>>>> 2) instead of '~' signifying the root node use
'/';
>>>>>>
>>>>>> 3) instead of ',' as a node separator in the address
(node path) use
>>>>>> '/'. so the format of an operation will look like
>>>>>>
>>>>>> [node-type=node-name (/node-type=node-name)*] : operation-name
>>>>>> ['('param=value (,param=value)*')']
>>>>>>
>>>>>> This (2 and 3) will make the path look more linux-like, so
hopefully
>>>>>> more friendly for an admin.
>>>>>>
>>>>>> 4) in the same spirit, the tab-completion for operations will
start with
>>>>>> './', e.g.
'./subsystem=web/connector=http:read-resource'
>>>>>
>>>>> or '/' to start from the root (if the current address
(prefix) is
>>>>> something other than the root). e.g.
>>>>>
>>>>> [subsystem=web/connector=http] /subsystem-threads:read-resource
>>>>>
>>>>>> 5) for the command names, Max likes
>>>>>> cn (change node) - current /prefix or /to.
>>>>>> cwn (current working node) - again current /prefix or /to w/o
arguments.
>>>>>>
>>>>>> I'd even go for cd to change the node. The reason I
didn't add it
>>>>>> originally was 'directory' doesn't belong here. But
cd is kind of habit
>>>>>> for this kind of thing, so I could add it as an alias.
>>>>>>
>>>>>> Any objections or suggestions?
>>>>>>
>>>>>> Thanks,
>>>>>> Alexey
>>>>>> _______________________________________________
>>>>>> jboss-as7-dev mailing list
>>>>>> jboss-as7-dev(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> jboss-as7-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>> /max
>>>
http://about.me/maxandersen
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> --
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> Dimitris Andreadis
>> Software Engineering Manager
>> JBoss Application Server
>> by Red Hat
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>
>>
http://dandreadis.blogspot.com/
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev