inspeqtorctl fails with nc: invalid option -- 'U' (workaround possible)

[tibra]

Dear Mike 👋,

calling the inspeqtorctl command fails:

inspeqtorctl
> nc: invalid option -- 'U'

Environment

Debian 10 Buster
Inspeqtor 2.0.0
netcat v1.10-41.1

Other projects seem to have similar problems.

It seems to be related to line 13 here:

if [ ! -x /bin/nc ] && [ ! -x /usr/bin/nc ]; then
  # Some OS's ship with nc in the base, others don't.
  # What a crock.
  echo Could not find a working netcat in /bin/nc or /usr/bin/nc.
  echo Please install your operating system\'s \'netcat\' or \'nc\' package
else
  echo "$@" | nc -U ${INSPEQTOR_SOCK:-/var/run/inspeqtor.sock}
fi

🔧 Workaround I can confirm, as suggested here, that the netcat-openbsd package on debian works, which supports the old cli and inspeqtorctl works as intended.

I can live with the workaround, but others may be wondering what goes on. Maybe you have an idea how to fix it without having another conditional.

Thank you kindly!

[mperham]

If I remove -U, will nc start failing on other platforms that do support -U?

[tibra]

Yes, it will then fail without providing a conditional or another solution to read the socket because the CLI changed (an since nowadays container images change their base images too, it might create regressions):

Options, that nc.traditional does not know are: -4 / -6, -U, -k Options, that nc6 does not know are: -U, -k but it knows --continuous

• Creating a conditional on inspeqtor's side is not straight forward and probably error prone because checking the version number requires parsing the man pages m(
• Requiring netcat-openbsd as a dependency would be an option, albeit contrary to the philosophy of a standalone library.
• Apart from that, socat seems to be an actively maintained and modern alternative.

Would it make sense to bundle this into the inspeqtor package if the OS cli env is not reliable enough?

[mperham]

Yeah we can change the packages and binary to install and use socat.