[wildfly-dev] cli variables

[Alexey Loubyansky]

I thought about adding the variables to the xml config. I think the xml 
config is more, kind of, a static and general config. While the 
variables seem to be more user-specific (user environment and perhaps 
task specific). So, I thought I'd separate them. And, yes, the idea was 
emulating .bashrc.

The content - yes, originally driven by variables. There could be custom 
command definitions and batches. All this could be put into the xml 
though but it felt like it'd be better to separate.

On 12/03/2013 06:05 PM, Brian Stansberry wrote:
> The basics of this sound good. I'm not sure about the .jbossclirc part.
> How would this file differ from the jboss-cli.xml file? Emulating
> something like .bashrc could be really cool, but if doesn't end up being
> a pretty close analogue, it could be confusing.
>
> So what kind of things could be done with this file?
>
> 1) Simple association of variable names with simple strings. Makes
> sense, but could also be in the xml file.
>
> 2) Execution of commands?
>
> Connect commands could make sense; eliminate boilerplate from the CLI
> launch command.
>
> Other commands, I'm not sure what that could be.
>
> 3) Definition of functions; e.g. take what would be a separate CLI
> script with multiple commands, in-line it and name it.
>
> 4) Others?
>
> On 12/2/13 8:09 AM, Alexey Loubyansky wrote:
>> There is this issue to provide CLI preferences
>> https://issues.jboss.org/browse/WFLY-1063. Here I'd like to address
>> mainly this part
>>
>> "prod-db = /subsystem=jadada/database=jadada/
>> so you could call prod-db:read-resource"
>>
>> I'd like to get some opinion on the way it's gonna be implemented (and
>> what I've done so far on a local branch).
>>
>> So, to address that I introduced variables. A variable starts with a $,
>> e.g. $prod_db. (Using simply prod_db is not a good idea since it might
>> conflict with actual parts of the paths, names, etc)
>>
>> Variables can be introduced with
>>
>> [disconnected /] set prod_db=/subsystem=datasources/data-source=ExampleDS
>>
>> Read with
>>
>> [standalone at localhost:9990 /] echo prod_db
>> /subsystem=datasources/data-source=ExampleDS
>>
>> And unset with
>>
>> [standalone at localhost:9990 /] unset prod_db
>>
>> 'echo' without parameters will list all the variables and their values,
>> 'set prod_db=' will have the same effect as 'unset prod_db',
>> set/echo/unset will work with and w/o '$' prefix, tab-completion works
>> everywhere.
>>
>> The variables may appear in:
>>
>> - operation request addresses, e.g. $prod_db/statistics=jdbc:read-resource;
>> - operation names, e.g. $prod_db:$op(include-runtime=true);
>> - operation parameter names and values, e.g.
>> $prod_db:$op($param=$param_value);
>> - the same for commands.
>>
>> Tab-completion helps complete the names as long as you type in '$' and
>> then the rest of the line after the variable as usual.
>>
>> Variables added during the session are not persisted anywhere. But I've
>> added .jbossclirc file. This file can be located in the current
>> directory, wildfly home bin directory or specified with a system
>> property. The content of the file is usual CLI commands and/or
>> operations. So, the variables could be initialized there. This file, if
>> located, will be executed before the CLI session (interactive or not)
>> starts (but also after the system properties specified with --properties
>> are set).
>>
>> As a side effect, '$' is now a special character and will have to be
>> escaped. Otherwise the CLI might complain about an unresolved variable.
>> So, this could potentially cause problems for existing scripts using $.
>>
>> Note, most of this replacement stuff can already be done with system
>> properties using ${xxx} format (and btw scripts using '$' as in '${xxx}'
>> won't be affected, of course).
>>
>> And for now I've made variable names follow the rules for Java identifiers.
>>
>> Any remarks, objections or suggestions?
>>
>> Thanks,
>> Alexey
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>