The test shows that in the case were "single0 on" is executed, VTY
function should return complete "single0 one" but it doesn't.
Related: OS#4045
Change-Id: Ib5b9dc07e2b280dc95011b3926afb1d490cadd81
inner block defined variable "enum match_type ret" was being masking
outter block variable "int ret = 0". The ret variable was being given
non zero values only inside the inner block, so that change was done on
the inner variable and not the outer one, which is returned.
Fixes: 5314c513f2
Change-Id: Iec87d7db49a096d07e38ff8a060b923a52bfd6ba
This patch is a result of discussion we had in [1]. The key idea
is that libosmovty should properly auto-complete the commands
containing choice, such as the following one:
multi0 (one|two|three)
[1] If9b0c0d031477ca87786aab5c269d00748e896c8
Right now, sending the following command:
(osmo-foo-bar)# multi0 th
would basically match the following vector:
multi0 three
however the resulting argv would be:
["multi0", "th"]
Moreover, sending the following command:
(osmo-foo-bar)# multi0 t
would basically match the following vectors:
multi0 two
multi0 three
because both start from 't', so the resulting argv would be:
["multi0", "t"]
which is ambiguous!
The expected output is:
(osmo-foo-bar)# multi0 th
ok argc=1 three
(osmo-foo-bar)# multi0 t
% Ambiguous command.
This is going to be fixed in the follow up patches.
Change-Id: I83c3aef813173952641035862c534ef16384780e
Since very recently we sensibly handle commands like
cmd ([one]|[two]|[three])
as optional multi-choice arguments. In addition, support the more obvious
syntax of
cmd [(one|two|three)]
Internally, the tokens are mangled to [one] [two] and [three], which is how the
rest of the code detects optional args, and makes sense in terms of UI:
> cmd ?
[one]
[two]
[three]
(i.e. optional arguments are always shown in braces in '?' listings)
Before this patch, commands defined with a syntax like [(one|two)], would lead
to an assertion (shows as "multiple") during program startup.
Change-Id: I952b3c00f97e2447f2308b0ec6f5f1714692b5b2
Add basic optional multi-choice argument support.
The VTY detects optional arguments by square braces.
> cmd ?
[optional-arg]
> cmd optional-arg
ok
> cmd
ok
However, within multi-choice args, these braces were so far not treated as
optional:
> list
cmd2 ([one]|[two]|[three])
> cmd2
% Command incomplete
In preparation for I952b3c00f97e2447f2308b0ec6f5f1714692b5b2 which will enable
the more obvious syntax of
cmd [(one|two)]
for reasons of internal implementation, first support a syntax of
cmd ([one]|[two])
The internal vty implementation always needs square braces around each option.
There is currently no good way to prevent developers from defining braces
inside multi-arguments, so it is easiest to allow and handle them:
> list
cmd2 ([one]|[two]|[three])
> cmd2
ok
The VTY doesn't guard against a mix like
cmd (one|[two])
With this patch, a multi-choice command is treated as optional iff the first
element is in square brackets. The remaining elements' square brackets have no
effect besides confusing the user. This is not explicitly checked against.
In general, I would prefer to check all of these details, but the current VTY
code with its endless code duplication and obscure string mangling just doesn't
provide that luxury. There are numerous worse errors hidden in there.
Change-Id: I9a8474bd89ddc2155c58bfca7bd038d586aaa60a
I want to tweak general VTY features and need to cover with a transcript test
to show the differences. Start by showing the current situation of optional
and multi-choice arguments.
Change-Id: I5a79c83fabd02aba6406b6e0d620969c4bd0cc1d
Pau Espin
Vadim Yanitskiy