Would it make more sense to extend the current -T flag e.g.
-Tfields,ip,udp,tcp.srcport
instead? This would tie the output spec directly to the "fields"
format. It might be useful to be able to restrict the fields in the
"pdml", "ps", and "text" formats as well.
Ian Schorr wrote:
> This would be great. I've been wanting something like this for years.
> I've been getting by using the -z "proto,colinfo" option, but there are
> so many cases where it isn't ideal for scripted parsing or importing
> decoded output into other tools.
>
> This plus a more advanced MATE would be a dream come true =)
>
> On 2/1/07, *Douglas Pratley* <Douglas.pratley@xxxxxxxxxx
> <mailto:Douglas.pratley@xxxxxxxxxx>> wrote:
>
> Hi all
>
> I'm looking at implementing a feature from the Wishlist that we
> would like as well: the ability to control the output of tshark e.g.
>
> tshark -Tfields -e ip - e udp - e tcp.port
>
> This new format would produce a line per packet, but would do full
> dissection. "ip" would dump out the whole representation for the
> "ip" field.
>
> For the command line parameters, I'm planning to enforce both an
> output type switch (-Tfields) and at least one field entry (-e).
> This leaves open the possibility of combining "-e" with other
> verbose options (pdml, verbose text) if people want it.
>
> I've picked -e because it was free and the example in the Wishlist
> uses it. I don't think it's particularly appropriate, but ones that
> might have been are gone.
>
> I also prefer to have multiple fields as multiple -e statements
> rather than one with a quoted, space separated list e.g -e "ip udp
> tcp.port"; largely because it saves having to add another layer of
> (admittedly trivial) parsing code.
>
> It would be good to also have options controlling how this works in
> detail:
> (a) An optional first "header" line listing the selected fields
> (b) An option to control the separator (I'm defaulting to tab
> because that doesn't tend to come up in Wireshark output)
>
> but I don't want to clutter the options list any more. Can anyone
> think of an elegant way to do this?
>
> I'd also like to hijack the -c option to only read in the first "n"
> packets of a file, rather than just for live capture as at the moment.
>
> Comments / suggestions?
>
> Cheers
>
> Doug
>
>
>
>
> This message should be regarded as confidential. If you have
> received this email in error please notify the sender and destroy it
> immediately.
> Statements of intent shall only become binding when confirmed in
> hard copy by an authorised signatory. The contents of this email may
> relate to dealings with other companies within the Detica Group plc
> group of companies.
>
> Detica Limited is registered in England under No: 1337451.
>
> Registered offices: Surrey Research Park, Guildford, Surrey, GU2
> 7YP, England.
>
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx <mailto:Wireshark-dev@xxxxxxxxxxxxx>
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
