[asterisk-dev] Standardizing CLI commands across modules

[Mark Michelson]

On 07/14/2010 10:56 AM, Steve Edwards wrote:
>> On 10-07-13 04:56 PM, Steve Edwards wrote:
>>      
>    
>>> I've been advised that I can do all this voodoo using aliases, but I
>>> suspect I'll lose command completion or some other feature if I go down
>>> this path and I suspect I'm not the only one who finds the current CLI
>>> obtuse.
>>>        
> On Wed, 14 Jul 2010, Leif Madsen wrote:
>
>    
>> Well the decision was made (for better or for worse) between 1.2 and 1.4
>> -- the discussion about the formatting happened a long time ago, so
>> there isn't much to be done about that there.
>>      
> I understand -- I've beat this horse before.
>
> I'm just frustrated that (in my opinion) the wrong decision was made and
> that there is so much inertia.
>
> Kind of reminds me of the old cliche of the husband blindly driving down
> the road refusing to listen to his wife begging him to stop and ask
> directions or turn around.
>
> Till next time...
>
>    
I've been thinking this whole time what a complainy-pants Steve here is, 
especially since there are templates that Leif has pointed out for 
maintaining backwards compatibility for changed commands. I've realized 
that it's a bit more complicated than that though.

For instance, if a 1.2 user is accustomed to the <verb> <module> 
[<option>] syntax for queues, then he can easily enable the asterisk12 
template when he upgrades to allow for the classic commands he's used 
to, like "show queues." However, there is an issue when trying to deal 
with CLI commands added in later versions. These new ones are almost 
certain to follow the <module> <verb> <option> syntax. Furthermore, 
since the command didn't exist in 1.2, we're not going to add the 
command to the asterisk12 template of cli_aliases.conf.sample. An 
example of this would be the "queue reset stats" command, which was 
added in 1.6.2. There is no alias for it in the asterisk12 template of 
cli_aliases.conf.sample. The result of this is that someone who upgrades 
will find the CLI commands to be inconsistent since they will have "show 
queues" and "queue reset stats" available.

I'm a huge proponent of the <module> <verb> <option> syntax myself. To 
me, it is much better for categorizing commands than the older syntax 
was. For instance, if I want to know what SIP-related CLI commands are 
available, I can type "sip <tab>" and see more options. This is much 
better than typing an available verb in and then trying to see if there 
is a SIP command that pertains to the verb. It also allows for the 
"help" command to list like options together instead of having SIP 
options mixed in with queue and CDR options.

Having said that, I do think that ease of upgrade is important, and so I 
propose something to help with transitioning: create a new 
cli_aliases.conf template that serves as a way of issuing new commands 
in the old style. This would be a home for all commands that do not have 
a 1.2 analog. For instance, the "queue reset stats" command could have 
an entry in this section that aliases the command as "reset queue 
stats." While this may seem like a burden for the developers to 
maintain, the task would only come up once every time that a new major 
release is to be made. It may come up at times for minor releases, too, 
but we tend not to add new CLI commands to point releases.

Is my idea reasonable, or should we leave the job of aliasing to those 
vocal few who are bothered by the current format?

Mark Michelson