On Mon, Mar 11, 2024 at 11:27:34PM +0100, Alexander Zubkov via Bird-users wrote:
Hi all,
I noticed in the new version 'show bfd sessions' was extended with 'all' option. But I also noticed that in case of 'show protocols', 'show ospf state|topology' this option comes before [name], but for 'show bfd sessions' it is the other way. I think it would be better to be consistent here and use 'all' keyword before [name] too.
Hi In fact, for 'show bfd sessions' you can use the option 'all' either before or after [name], as there is no fixed order of options for this command. In documentation, there is an order in which they appear, e.g.: show bfd sessions [<name>] [address <ip|prefix>] [(interface|dev) "<name>"] [ipv4|ipv6] [direct|multihop] [all] but that is just simplification, they can be used in any order. In general, there are commands that have a few options and depend on fixed order (e.g. 'show protocols' or 'show ospf neighbors'), and there are commands that have more complex options, use key/value scheme and allow options in arbitrary order (e.g. 'show route', 'show ospf lsadb', or 'show bfd sessions'). I think that the first scheme is lazy and non-extensible, and most commands should be converted to the second scheme.
I also noticed some incompleteness of the "Remote control" documentation now. I.e. it lists: show protocols [all] When it is actually: show protocols [all] [<protocol>|"<pattern>"]
Yes, that is missing.
Also "show route ... [options]" does not have clear description of what these options are.
Not sure if you mean interactive help or reference documentation, as in the documentation they are described: https://bird.network.cz/?get_doc&v=20&f=bird-4.html#cli-show-route (but of course, it could always be improved.)
It seems there are ways to improve this part of the documentation. I can offer a hand to examine it in more details what else might be missing and maybe prepare patches.
You are welcome. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."