<-
although this works
# nsd-control stats_noreset | sort --sort=general-numeric
<-
although this works
# nsd-control stats_noreset | sort --sort=general-numeric
Hi Shmick,
<-
although this works
# nsd-control stats_noreset | sort --sort=general-numeric
For nsd that would be feature bloat. The pipe and sort invocation
that you give is a much better way to do this, with purposeful
programs dedicated to their task.
So, I think it would be better to have sorting in 'sort', and not
implement it in nsd-control (and nsd).
Best regards,
Wouter
a message of 44 lines which said:
So, I think it would be better to have sorting in 'sort', and not
implement it in nsd-control (and nsd).
+1 (as a general way to answer users' features requests).
W.C.A. Wijngaards wrote:
Hi Shmick,
<-
although this works
# nsd-control stats_noreset | sort --sort=general-numeric
For nsd that would be feature bloat. The pipe and sort invocation
that you give is a much better way to do this, with purposeful
programs dedicated to their task.
fine with me
So, I think it would be better to have sorting in 'sort', and not
implement it in nsd-control (and nsd).
what were the original decision making processes based upon that gave
rise to the current sorting method of the RRs ?
Hi Shmick,
So, I think it would be better to have sorting in 'sort', and
not implement it in nsd-control (and nsd).what were the original decision making processes based upon that
gave rise to the current sorting method of the RRs ?
Well, it is a copy of the unbound functionality, and follows the same
sorting in parts. That has similar data printed together (that makes
it grouped in the code as its source is often also from a similar data
structure). The rr-type data is printed by the RR type number
ascending (because that is what the array is indexed with).
Similarly for RCODEs, RRclasses and so on, by ascending number.
Best regards,
Wouter