On Wed, Jan 24, 2001 at 10:48:08PM -0800, Guy Harris wrote:
> On Thu, Jan 25, 2001 at 02:22:38PM +0800, Visser, Martin (SNO) wrote:
> > Maybe when someone gets a chance we should look at changing the "Filter"
> > button to actually understand the context it is in
>
> The underlying code, at least at the top of the CVS tree, *does*
> understand that - depending on the context, the "Filter" button either
> causes "capture_filter_construct_cb()" or
> "display_filter_construct_cb()" to be called.
>
> However:
>
> > and either "dim out" the
> > wrong filter type , save display /capture filters with a different flag, or
> > even convert between the two (where possible)
>
> the file in which filters are stored currently doesn't distinguish
> between capture and display filters; the file just has lines consisting
> of a quoted string containing the filer name and a list of tokens that
> make up the filter expression.
>
> I.e., the problem isn't with the filter dialog box code understanding
> the context, it's with Ethereal simply not distinguishing, in the filter
> list, between capture and display filters.
>
> Were we to distinguish between them, we'd probably want to have two
> separate files.
Well, I just checked in code to do that.
Ethereal now tries to read "~/.ethereal/cfilters", to get a list of
capture filters, and "~/.ethereal/dfilters", to get a list of display
filters.
If, when it tries to open either of those files, it finds that the file
doesn't exist, it tries to read "~/.ethereal/filters" instead; this
means that we start out with the capture and display filter lists
containing all of your previously-saved filters. You can then use the
"Edit->Capture Filters" or "Edit->Display Filters" menu item to delete
from either of those lists filters that don't belong.
(We could, I guess, add filters to the display filter list only if
they're syntactically-valid display filters; it's harder to do that for
capture filters, as, in most versions of libpcap, you can't attempt to
parse a capture filter unless you've opened a capture device, and that
often requires root privileges, and requires a capture device you can
actually open, and.... The API, on those versions of libpcap that *do*
let you parse capture filters without opening a capture device, has
multiple flavors, not all of which are compatible with one another. No,
you can't assume that a given filter expression is either a capture
filter expression or a display filter expression - "tcp" works for
either one.
I figured that simplicity was the better part of valor, here. Anybody
who wants a better scheme for constructing the two filter lists from the
one and only one filter list that previous versions of Ethereal
supported is more than welcome to implement it or to get somebody other
than the author of this mail message to implement it; make sure you
don't break anything on any platform, and that it doesn't require root
privileges....)