On Thu, Mar 28, 2013 at 1:18 AM, Hadriel Kaplan <hkap...@acmepacket.com> wrote: > > On Mar 27, 2013, at 10:38 PM, Evan Huus <eapa...@gmail.com> > wrote: > >>> So why make it optional? >> >> Because -2 causes tshark to buffer, which we shouldn't be imposing on >> the user 'by accident'. Additionally, if we keep -2 a separate option >> then -d will be usable during a live capture, which fixes another >> long-standing issue in tshark. > > You lost me... why would '-d'/'-Y' be usable during a live capture, but '-R' > not? > > I thought '-R' was only *unusable* with live capturing when the '-w' writing > output file was also set, on purpose due to concerns of privilege separation > (ie, bug 2234). I put the same restriction in my patch for '-Y': it can't be > used if both live-capture and writing to file are set.
I clearly shouldn't be writing emails that late at night :P (I'm also currently looking at bug #8317 which is in the same code neighbourhood as both this issue and bug #2234, and somehow I got them all mixed up). Live capture doesn't even enter into it, you're right. Allow me to try that again: - We need to keep '-2' around for the case where the user wants to do 2-pass analysis without any filtering. - Buffering is unfortunately necessary behaviour, but still confusing. We should impose it only if the user explicitly asks for it (with -2). - While -d and -R would be effectively identical during 1-pass analysis, it seems to me that conceptually -R is the odd one out. There's no need to do a read filter if you're never going to look at the packets again, while you might still want to control what is displayed. It's possible we may want to go as far as forbidding -R without -2 just to enforce the conceptual distinction. This would have the advantage that then -R would *always* renumber packets, (while -d never does) which is at least a win for consistency. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe