Tim Dawson writes:
> LISTEN 1.2.3.4 2.3.4.5 987
>
> is a mess . . . You either need to specify the default port number, or
agreed that this method is a mess!
But we have "just use multiple listen statements" which is
straightforward.
I am not really averse to having a format that is a more
But yet again, in a manner inconsistent with what is most commomly seen.
*Consistency* across a platform (*nix, whatever) goes a long way, and doing
something differently out of arrogance, or just to be different it rather
nonsensical . . .
On April 30, 2024 3:43:01 PM EDT, Jim Klimov via
Just in case, to the last couple of posts speaking of multiple listeners:
NUT does allow specifying several lines of `LISTEN host port` to handle
multi-homing and whatnot. A reminder to readers who might not realize this
possibility exists already.
Jim
On Tue, Apr 30, 2024, 18:00 Kelly Byrd
IMO, if NUT is going to offer "host and port" in the config, It should be
host:port. That will surprise the fewest people. Spaces can then be used to
separate multiple entries (host1:port1 host2:port2)
I do NOT think you need to go down the "resolve service name string to
port".
On Mon, Apr 29,
"why would anyone want to use "host:port" when "host port" works? That
just seems like "I want to rewrite the config format, because [why?]."
I see the host:port nomenclature in a *lot* of software, and the one thing it
gives is far easier parsing of multiple listen address:port pairs.
IE, to
Jim Klimov writes:
> Just to clarify: using a different port *is* possible since forever, with
> `LISTEN host port` (as two arguments to the directive); the question was if
> having a way to spell it as one argument as `LISTEN host:port` would solve
> some shortcomings/ease adoption more than
Thanks for sharing your take on this. (Sorry about likely mixing historic
standards, was not in position to cross-check while posting)
Just to clarify: using a different port *is* possible since forever, with
`LISTEN host port` (as two arguments to the directive); the question was if
having a way
Jim Klimov via Nut-upsdev writes:
> A recent discussion in the issue tracker brought up the idea to allow the
> `LISTEN` keyword to also accept a single "host:port" token (e.g. if there
> is only one argument, with at least one colon, and the last colon is
> followed only by numbers, split it
