On 2025-12-28 Adam Thompson wrote:
I think you might be able to suppress the error output by redirecting the outer shell's stderr to /dev/null, but I'm struggling to see where either grep instance could possibly see its stdout vanish without warning! I'm not 100% convinced the error message is actually coming from grep, rather I think it might be coming from the shell instead.
That could very well be. The shell saying "grep is gonna have this problem, and I'm telling you"?
I would also not use nmap for this, I suspect fping will be far
Doh, now you tell me! :-) Ya, fping does exactly what I need without all the tricks. I never knew it existed. It's in Fedora's repos so that's good enough for me. I settled on: fping -q -r 1 -t 1 -X 1 -S ... { # clear! } Some other options look promising but as soon as you start fiddling with counts and timeouts it switched into "run a lot, output a lot" mode for some reason, even with -q. I'll have to just assume the defaults for these things are sane. Yup, run in an always-running script, started from systemd for autorestarts, runs every few mins and restarts things that seem busticated and systemd didn't/can't handle. Yes, this one bit is to paddle-resuscitate the lan/nic should the 25+ hosts all suddenly disappear. Usually due to whacked out or dying NIC, or whacked out or dying switch(/port). Rarely hits, tries a fix, and notifies me to look into it. As for the spurious pipe error, I'll safely ignore until I ever need to try that self-killing hack again! Thanks!