Returning a script input parsable form from pywbemcli for redirection to other tools

[KSchopmeyer]

While it is a basic concept with many scripting environments to attempt to return something from a command execution that can be used to create command pipes using redirection, we did not explicitly include that concept within pywbemtools responses. Our responses are often aimed more at display than at command chaining significant formatting, header lines for tables, etc.

We do not include output formats that are clearly designated to be able to redirect the returned information for further processing whether it be through files or the pipe operator.

The current pywbemtools format groups are

1. For CIM object type output which is intended to present a reprentation of each CIM object
   • MOF - corresponds to the DMTF specification of MOF for CIM objects. However, since there is no
     MOF representation for name objects they are presented as URLs.
   • XML - XML which corresponds to DMTF specification for CIM Objects per DSP0200 and DSP0201. Bothe cim objects and cim names have an XML representation
   • REPL - representation of the objects in python. This outputs what is defined in the __repl__method for the cimobject and normally is effectively the equivalent of a python call to create the object. Both CIM objects and CIM name objects have a REPL display.
   • txt - Simple string representation but taken from the str representation for each pywbem CIM object and today is almost worthless.
2. Table Outputs -
   a. General Output in a number of table formats including: table|plain|simple|grid|psql|rst|html where the differences are in formatting of the cells in the table and which vary from very complex display lines around each cell to the plain format which uses only spaces. Note that each table can include a header line that provides column names for the table and also a title line that is included with all of the table formats.
   b. CIM objects - the table output attempts to present a table based view of the CIM object including key attributes:
   • for instances: class name, instance properties
   • for instance names/paths: classname, namespace, host name, key property values the value of the classname, namespace, and key names.
     c. Other tables - We use tables as a general output for a number of other outputs (connection list, statistics, etc.).

In general the output for tables is as a list of lists where each inner list is a row and each item in that list is the value in a cell. The Header row is passed as a separate list (but could also be the first row) to the common function . The Title is passed as a separate

Some alternatives for parsable output formats:

1. Lines with clearly understood syntax to separate elements
   a. Using space as a separator - Modify the table "plain" format
   b. Use a CSV (comma-separated-values) which would output the row, column array the same as the table format except that it would format with comma-separated cells.
2. JSON that clearly separate elements and allow multidimension output formatting.

Note that our current support libraries (tabulate) do not support either CSV output or json.

Defining a Parsable output format

We have valid formats for cim objects that can be used by other tools as text (MOF. URL) in the MOF and XML output formats. which are complete, and documented as DMTF standards

However for tables in general we do not have a clean parsable output form for all of the other outputs which are largely tables such as connection list, etc.

It was proposed that we should use the plain format for this ("plain" is the format that puts no cell markers around each cell but insures that there are spaces between each cell in a row and NL for each row.

While the table output if presents a format that is displayable in a terminal (width limited, table cell boundaries, table formats compatible with a number of different display formatters, we do not have a table output that is really parsable on a line by line basis where each line would represent a row of the table and with a known separator between columns. The issue are:

1. Generally we are fold string based cells because to keep the display within reasonable width limits.
2. We do not provide a clean column separator because we do not process the strings to insure that any string that have spaces or embedded quotes are properly formated.
3. We fold long strings into multiple lines
4. We had a title line to the table display.

Using the text format:

TODO: