1.7.5 release ignores -q switch

[poorting]

Earlier versions of nfdump (and development versions leading up to 1.7.5) suppressed the header line when outputting csv formatted data if the -q switch was used.
The 1.7.5 release version now seems to always include a header line when generating csv format, ignoring the -q switch.

This messes up tools/pipelines that do not expect header lines when using the -q switch, so for consistency it would be nice to have the -q switch operate as before.

[phaag]

The csv output has been rewritten and is more flexibel now, as it accepts the same flexibility than fmt does. If you use
-o csv:%ts,%td,%pr,%sa,%sp,%da,%dp,%pkt,%byt,%fl you can create your own customised csv output. This requests to have an index line, which describes the fields used in the output, otherwise the interpretation is wrong.
I understand the issue, but I would like to keep the index line to improve parsing with user selected output format. Yes - it means an update on the parser side, but in all it improves flexibility.
Can you live with that?

[poorting]

The issue is not so much the new flexible format (which is indeed a nice idea!), but the inconsistency of the -q switch between versions that already supported the new format; which means an additional check is needed (in addition to check on old or new format).
If nfdump export is used as part of (and under control of) a parsing pipeline then the format is known surely, since it is the pipeline that specifies it; so header line is superfluous then. And if the default is to have a header line I don't understand why the possibility to leave it out has to be removed?
In the end no biggy, everything can be programmed and checked of course, I just failed to see the logic of removing it.

[phaag]

The old format was fixed and could not be changed, therefore you always have the same output, with or without the switch. If you use the flexible output, and use the switch -q you don’t necessarily know what fields you get in the output. Therefore the tag line is always printed. That’s the logic. Yes - you could argue, if you run the pipeline you know what to expect, but I think it’s more safe to read the tag line first and automatically decode accordingly..
Yes - it may be incompatible, but if you replace nfdump, you can adapt also the pipeline.
As a result I will point out the incompatibilities even more in future releases, if any.
I apologize for the extra work on the user side! 😔