[jboss-as7-dev] proposed cli changes

Brian Stansberry brian.stansberry at redhat.com
Mon Mar 14 12:35:43 EDT 2011


On 3/14/11 6:10 AM, 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.
>

We need to think about the security implications of this. Implementing 
it basically means recording a history of commands in some store somewhere.

As an aside, for people playing with the CLI, you can actually bounce 
the server, rebuild, do whatever, without closing the CLI process. If 
the next time you type a command the server is available, it will all work.

No promises this will continue to be the case, but for now it's a 
convenient way to keep command history -- just keep the process alive. ;)

>>
>>> +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 at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>> _______________________________________________
>>>>>> jboss-as7-dev mailing list
>>>>>> jboss-as7-dev at 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 at 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 at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat



More information about the jboss-as7-dev mailing list