On 2018/12/22 16:44, Daniel Jakots wrote: > Hi, > > With nc(1) you can do: > nc -zv example.com 80 > or > nc -zv example.com http > which does the same. This works well unless the service name has a dash: > $ nc -zv example.com syslog-tls > nc: service "tls" unknown > > This is because nc(1) is able to do some port scanning and the > delimiter used for the range is the dash. When it sees a dash, it > thinks it's a port range. > > nc(1) is not the only software that takes an input that can be a port, > a range or a service name: pf is in this case too. In pf the delimiter > used is ":" so this works fine. > > Here's a diff that change the delimiter to ":". This breaks existing > scripts but it would make the syntax like pf.conf instead of using > another symbol for a port range. > > If you have a better idea how to solve this problem, please share!
I think it's too late to mess about with the common syntax for scanning (i.e. "nc -zv foo 1-1023" or similar). It isn't just us - some other OS use OpenBSD as upstream for nc. But I can't imagine scanning a range by name as being much used (tcpmux-socks or something just doesn't make sense). What I think would be least disruptive is to continue to allow - where the rest of the parameter is numeric. For alphabetic parameters try parsing the whole word as a service; use it if valid. If not, *either* it could just error out (simple and unambiguous) *or* it could try parsing as a named range. But I don't think you will hurt anyone by just erroring out in that case.
