I'm looking into whether it's possible to automatically resolve expressions when
executing operations and commands in the CLI.
From my understanding, there are two variations of the problem.
* Operations are server-side processes that are accessed via ':' in the CLI and,
currently, the CLI presents the results returned as-is to the users. ex:
':read-resource'
* Commands are processes that get manipulated by the CLI before getting presented to
users. ex: 'ls'
I've been experimenting with adding arguments to the CLI commands, like 'ls
--resolve-expressions', and gotten it working for the standalone and domain side of
things. However, I can't control the scope of the argument, so it's available in
situations that cannot accurately resolve expressions like the 'profile=full'
section of the domain tree. The results wouldn't be reliable.
The same problem would apply to adding parameters to the server-side operations. The scope
of the operations themselves can be controlled, but not their parameters. An execution
like ':read-resource(recursive=true resolve-expressions=true)' can't resolve
expressions unless it's used against an actual server or host, but the operation is
available almost everywhere. Again, the results wouldn't be reliable.
I'm wondering if anyone can suggest a way to attack this problem? There is already a
':resolve-expression(expression=___)' operation, so users can somewhat laboriously
get the runtime values they want, but I can't figure out a way to integrate the values
into the existing framework successfully. Other than creating entirely new operations and
commands, like 'ls-resolve' and ':read-resource-resolve', which seems like
an unsustainable way to solve the problem.
Thanks,
Joe Wertz