While I am not saying Diversion's code is doing this, I ran into such an occurrence before using
grep -c
in my own codings, my fix was to change to
wc -l
(or it might have been vice versa) or add alittle more logic to the
grep -c
to know that it was counting an unintended line. I honestly don't suspect your code of doing this either. I believe some more details are in order to actually indicate the issue. I have yet to run into any issues on my tests runs.
@thelonelycoder
Upon further review of diversion, the only way diversion script could be counting the lines wrong is if there are lines with whitespace characters , or characters which have not been properly dealt with either in the grep command logic, or filtered out of the list processing by some other means.
eg.
/opt/bin/grep "^[^#]" test.fs | wc -l
content of test.fs
Code:
somelist
and
#list with space
output count
Code:
RT-AX88U_Pro:/tmp/home/root# /opt/bin/grep "^[^#]" test.fs | wc -l
3
something like
/opt/bin/grep -E "^[^#[:space:]]+([[:space:]]|$)"
would be more forgiving as the output in this case would only be
2
instead of
3
; otherwise there are unintended characters finding their way into the blocklist if the users reporting the issue is correct. We still have to see more details to support their claims though. For example, what does their blocklist actually consist of? Are they manually editing the blocklist directly themselves? There are a lot of things that need to be investigated.