[dns-operations] announcement of new tool -- dnscap
Paul Vixie
paul at vix.com
Fri May 4 03:42:17 UTC 2007
> > I was bitten by the "binary garbage all over stdout" problem so I
> > think "-d -" is a good idea.
ok.
> > If the user doesn't give a -d option then I think dnscap should
> > either (a) tell the user that no output will be generated, or (b)
> > use a default dump file name, or (c) popen("tcpdump -n -r -").
>
> (b) is bad, as the user really doesn't want to be stuck debugging a
> cryptic 'unable to write file' error when they run it in a non-writable
> directory without specifying a file. (a) is good.
i can live with that. does this mean i can omit the -d part, and have
the basename of the dump files be an actual command line argument rather
than an option introduced with -d?
> $ ls | bzip2
> bzip2: I won't write compressed data to a terminal.
> bzip2: For help, type: `bzip2 --help'.
i don't want to call isatty() so i'm glad nobody proposed that method.
--- on another note:
if i add a "-g" option to display the results dig-style, then the bind9
dependency will expand somewhat. you'll have to ./configure --enable-libbind
when you install bind9 (it's not built or installed by default). this is
because the "print things the way dig does" logic in bind9 is built into the
dig sources, whereas in bind8 it's in the library. does this requirement blow
out the idea of the "-g" option?
(can you all see why i'm workshopping this code on dns-operations@ rather
than namedroppers at ietf or dnsop at ietf or bind-workers at isc?)
More information about the dns-operations
mailing list