Carter Bullard | 25 Jun 2012 15:58

output field specifiers and command-line options - who wins ?

Gentle people,
With the " filling out " of the field format specifiers, where you can specify
the output format for any field like decimal, hex, string, etc… there are some interesting
situations to deal with.  Your opinions will be most appreciated.

As a reminder, this feature is there, primarily, to support database integration and use,
but its not limited to just that case.

If you specify for an address or a port, or protocol to printed out using decimal ("%d")
or  unsigned int ("%u") or a string "%s" formats, does this completely over-ride the
use of the " -n " option ?

I personally believe that it should.  

As an example,  if you are printing names for addresses, based on the " -n " option or
the RA_PRINT_NAMES option in the .rarc file, but you specify on the command line
that you want them printed as unsigned int's:

   ra -S localhost -s stime dur saddr:8:%u daddr:8:%u - ipv4

shouldn't we print out the unsigned int representation ?  Is the command line over-riding
the defaults, or other configurations that may be in play ?

If not, regardless of the specifier on the command line, if you're printing out
ascii strings for a given field, based on the " -n " option, we'll give precedence
to that format.

But, if you were to do this:

   ra -S localhost -s stime dur saddr:8:%u daddr:8:%u -nnnn - ipv4
(Continue reading)


Gmane