[Feature request] Quiet mode for the standard error channel

[GD1200]

While tcpdump provides the argument -q to reduce the amount of data printed to the standard output channel, I could not find a way to do the same for the standard error channel. When scripts/programs are executed by Cron, it is often desired to suppress all non-error messages, not to cause Cron to generate emails for expected output but only when errors occur. However, when tcpdump is executed, some lines are printed to the standard error channel unconditionally, leaving tcpdump users with the options to suppress the whole standard error channel along with possible error messages or to apply some sophisticated filtering to it.

For example, below are the standard error messages that do not represent real errors per se:

# timeout 3 tcpdump >/dev/null
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel

... so it would be great if there is an easy way to suppress them while still printing real errors like these ones:

# timeout 3 tcpdump -i eth1 >/dev/null
tcpdump: eth1: No such device exists
(No such device exists)

As expected, if we suppress the whole standard error channel, both expected and unexpected messages sink into oblivion:

# timeout 3 tcpdump >/dev/null 2>&1
#

# timeout 3 tcpdump -i eth1 >/dev/null 2>&1
#

I checked the latest master code, but could not find any conditions that can help suppressing the expected lines.

Thank you.

# tcpdump --version
tcpdump version 4.99.5
libpcap version 1.10.5 (with TPACKET_V3)
OpenSSL 3.3.1 4 Jun 2024
64-bit build, 64-bit time_t

[infrastation]

The original reason for printing informational messages on standard error likely was to avoid breaking/complicating various parsers of the packet decoding. That said, the point you make about cron jobs looks sound. One potential way to implement it would be to introduce an explicit flag like --cron or --errors-only-on-stderr. I suspect hinging this on isatty() would not work well.

[GD1200]

The original reason for printing informational messages on standard error likely was to avoid breaking/complicating various parsers of the packet decoding.

I fully agree on that. I guess that is especially required when raw packets are written to the STDOUT.

One potential way to implement it would be to introduce an explicit flag like --cron or --errors-only-on-stderr.

I believe the latter is a better choice as there might be more use cases for the need to suppress info-level messages on the STDERR. I think a flag like --pure-stderr can also convey the idea in a shorter way. :)

[fxlb]

--strict-stderr?
Or with a parameter:
--stderr errors or --stderr strict (default --stderr all)

[fxlb]

Or --stderr level with level:
0: Information/all (default)
1: Warnings
2: Errors (with exit)
e.g. --stderr 1 print only warnings and errors (>=1).