Ah. Your point is that the strings are different? CLI says 'Rtr' tag says 'isrouter'?
I can't relate this being a problem, sorry. The data is there, you can classify and reprint it as you wish. On 9 March 2018 at 12:37, Martin T <[email protected]> wrote: > On Thu, Mar 8, 2018 at 11:51 AM, Saku Ytti <[email protected]> wrote: >> Hey Phil, >> >> I'm hijacking this for a bit. >> >> You have | display json and xml, I assume json was relatively modest >> amount of work, as you have formal source of data, so someone only >> needed to write translator, without being aware of all context to >> support | display json, which also means, no one needs to do any work >> to get display xml or json to work on new command introduced? >> >> If this is remotely true, shouldn't it be equally possibly to present >> all data over SNMP which is presentable as JSON and XML? There are >> bunch of gaps on relatively important stuff, which I'd love to see >> available in SNMP. This week particularly I was frustrated to find how >> 'show class-of-service fabric statistics' is not available over SNMP. >> Perhaps introduce some CLI-MIB where all json/xml supporting commands >> are generated in OIDs and command in CLI to ask OID for particular >> command? >> >> >> >> >> On 8 March 2018 at 07:26, Phil Shafer <[email protected]> wrote: >>> Martin T writes: >>>>I have noticed that certain commands executed on CLI provide some >>>>additional information over corresponding RPCs. For example "show ipv6 >>>>neighbors" or "show system storage" on CLI show column names while XML >>>>output does not contain this data. Why is that so? >>> >>> Both the CLI and RPC content contain the same information, but the >>> CLI takes the data supplied by the RPC and displays it using rules >>> specified by the developer. These rules include column headers, >>> field titles, and other gritty little details. >>> >>> But these are "display" features. The API is meant to allow access >>> to the data, and to make that data the same data used by the CLI, >>> so the API is complete, up-to-date, well-tested, and useful. >>> >>> If you want to use the API to get pure text data, we do have the >>> 'format="text"' attribute that can be put on an RPC. >>> >>> Thanks, >>> Phil >>> _______________________________________________ >>> juniper-nsp mailing list [email protected] > >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >> >> >> >> -- >> ++ytti > > Hi Saku, > >> I don't follow you, the 'column' names are not needed, as they are in the >> tags? > > Column names are not in the tags. For example, consider a use-case > where you want to print the output of "show ipv6 neighbors" similarly > to table format of BSD column utility and you would like to use the > same column names as the output of "show ipv6 neighbors" CLI command. > One way to do this is to manually create a node-set variable for the > column names: > > "var $column_descr := { > <ipv6-nd-entry> { > <ipv6-nd-neighbor-address> "IPv6 Address"; > <ipv6-nd-neighbor-l2-address> "Linklayer Address"; > <ipv6-nd-state> "State"; > <ipv6-nd-expire> "Exp"; > <ipv6-nd-isrouter> "Rtr"; > <ipv6-nd-issecure> "Secure"; > <ipv6-nd-interface-name> "Interface"; > } > } > > ..and generate another node-set variable using > "get-ipv6-nd-information" RPC and finally use the union operator(|) to > find the longest row in each column and print the output accordingly. > > > Phil, > >> Both the CLI and RPC content contain the same information, but the >> CLI takes the data supplied by the RPC and displays it using rules >> specified by the developer. These rules include column headers, >> field titles, and other gritty little details. > > Thanks! That's what I suspected. Looks like for example in case of > "show ipv6 neighbors", cli process calls nd6info binary which contains > the column names and statically set printf format string. > > > regards, > Martin -- ++ytti _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
