[LiSA-Devel] CLI_EX_* significance/usage

[Ionut Nicu]

Hi Andreea,

On Tue, 2013-03-12 at 10:16 +0200, Andreea-Cristina Hodea wrote:
> Hi,
> 
> I've fixed the following in cli/command/config_if.c:
> -      if_change_addr(cmd, if_addr->ifindex, if_addr->inet,
> if_addr->prefixlen, 0, NULL);
> -      // FIXME check return value of if_change_addr()
> +      if (if_change_addr(cmd, if_addr->ifindex, if_addr->inet,
> if_addr->prefixlen, 0, NULL) < 0) {
> +        ret = CLI_EX_REJECTED;
> +        goto out_cleanup;
> +      }
> 
> but I'm not quite sure when a handler should return CLI_EX_REJECTED
> versus CLI_EX_WARNING. If we are here, when/where would CLI_EX_NOTIMPL
> aplly?

I think you should check in rlshell.c (btw, the rl prefix stands for
readline) for the rlshell_exec() function. Both REJECTED and WARNING are
meant for error cases, but the output is different. I think we were
trying to emulate the Cisco CLI behavior and there were 2 different
cases "Command rejected: <reason>" and the second case where just an
error message "<reason>" was displayed.

Again, it's been some time since we wrote that code, and I have to admit
I may have forgotten some of the details :-)

NOTIMPL was meant for CLI handlers that were not implemented yet,
although they showed up as available commands in the CLI (with
completion & all). Currently I think it's not used anywhere, but we
should keep it until we implement all of the commands.

> 
> Also, if removing one of the addresses fails, should the handler
> continue to try removing the other addresses and just set ret
> correspondingly?
> 

I think we should try to do our best to remove all addresses. If one
fails for some reason, we should set ret and the reason accordingly
(probably to CLI_EX_WARNING and an error message) and continue trying to
remove the other addresses. Probably the check for 
if_get_addr() return value should do the same, instead of just jumping
to the cleanup label.

You can use the EX_STATUS_REASON_...() macros for error reporting.

For most of the commands you should try to see what a real Cisco switch
outputs and try to make it closer to that, so our users get a familiar
behavior.

Ionut.