Am Freitag, 7. Mai 2010 12:33:38 schrieb Christof Hanke: > One more thing, > > I have implemented something similar for the osd-command, but only csv , > ASCII and HTML (simple table). > > I did this by adding a complex struct table to libcmd.a, so that it is > available to all commands linking to it. > > ATM, it can only output simple tables (with one Header- and one Footer-line > if given). > > You can also sort by one column. > E.g. > # ./vos partinfo afs14.rzg.mpg.de -ttype 1 > > Partition,FreeSpace,TotalSpace > /vicepa,120201568,1928200192 > /vicepg,170753232,1702836224 > /viceps,211810376,1597898752 > /vicepw,27915468,235865600 > > > # ./vos partinfo afs14.rzg.mpg.de -ttype 1 -tsort 2 > Partition,FreeSpace,TotalSpace > /vicepw,27914820,235865600 > /vicepa,120201568,1928200192 > /vicepg,170753232,1702836224 > /viceps,211810376,1597898752 > > Unfortunately, there is a problem ATM with my Yahoo-OpenID and gerrit, so I > can't push it up there, but you can find the patches against master here: > > /afs/ipp-garching.mpg.de/u/hanke/public/openafs/tabular_output.patch > /afs/ipp-garching.mpg.de/u/hanke/public/openafs/tabular_output_example.patc >h > > Maybe we can integrate the xml output there ? I guess it should be > possible. > > Christof I could now thanks to Simon push this to gerrit. See Change-IDs Id0a00d996a94fee08538226317c60e5bf5082051 and Ic433cf56337879251105d2de4aca9fd2ddd1477b
> > Am Donnerstag, 6. Mai 2010 16:37:32 schrieb Andrew Deason: > > Just one thing... > > > > On Thu, 6 May 2010 15:01:45 +0200 > > > > Sanket Agarwal <[email protected]> wrote: > > > On Wed, May 5, 2010 at 5:15 PM, Steve Simmons <[email protected]> wrote: > > > > /* Print value of spare3 field as integer */ > > > > if ( type == RAW ) > > > > fprintf( STDOUT, "%spare3\t\t %d (Optional)\n", value ); > > > > else if ( type == XML ) > > > > fprintf( STDOUT, "\t\t<spare3>%d</spare3>\n", value ); > > > > else if ( type == CSV ) > > > > fprintf( STDOUT, "%,%d", value ); > > > > Once we get to multiple output formats, I'd have thought this to turn > > into arrays of function pointers, instead of several if/else ladders (a > > la the cache types in the client code). So you'd have something like > > > > output_type->print_spare3("spare3", value); > > > > And you'd define > > > > static struct vos_output raw_output = { > > /* ... */ > > .print_spare3 = print_raw_int_optional, > > /* ... */ > > }; > > > > static struct vos_output xml_output = { > > /* ... */ > > .print_spare3 = print_xml_int, > > /* ... */ > > }; > > > > static void > > print_raw_optional(const char *name, int value) > > { > > fprintf(STDOUT, "%s\t\t %d (Optional)\n", name, value); > > } > > > > /* ... etc */ > > > > Or whatever. And use one of those structs depending on the -format > > argument. > > > > So, you don't have entirely separate enumeration functions, etc. What > > values you print and in what order are the same for all; the only > > difference is how they are output. In theory I think the problems in > > e.g. SubEnumerate that Steve mentions are surmountable if you just give > > each callback function enough context. > > > > But I don't know, a lot of the logic is still scattered, so I don't know > > how much better that would be. Just a thought.
