On Thu, Jun 10, 2010 at 04:38:21PM -0000, Grondr wrote:
> Wait, what? Are you saying that nc -should- accept -p with -l?
Of course. Otherwise it'd be pointlessly incompatible with the old
netcat.
> In other words, that "nc -l -p 1234" is the same thing as "nc -l 1234"
> in OpenBSD nc?
No, it /is/ not. It should be.
> But that wasn't what the manpage seemed to indicate -at all-.
No, because it's not the case now.
> It goes out of its way, in several places, to claim that this isn't
> possible,
It's not. From netcat.c:
if (lflag && pflag) errx(1, "cannot use -p and -l");
We should just change that.
> yes, changing this will restore a huge amount of compatibility with
> the traditional nc, and I don't understand why OpenBSD went out of
> their way (in both the code and the manpage) to make this not work in
> the first place.
Well, having to pass -p /is/ kind of silly. If you want to listen, you
want to specify a port on which to do so, so making you pass the -p
*option* only makes sense because of tradition.
> P.S. You say you don't know where I was going w/my comment about
> "broken" vs -l -p. I was simply trying to say that the current (bug?
> deliberate change?) to the behavior of -l -p made it look like nc
> simply couldn't be used as a listener at all, and that, when I wrote
> the report, I hadn't yet discovered that the manpage for the OpenBSD's
> version claimed that -l -p was simply incorrect usage (based on what
> looked like a non-upward-compatible change) that that's why I was so
> intemperate in my tone---until I found what looked like a deliberate
> change in semantics (which you now say is a bug---I agree!), it looked
> like the intended way to use nc as a listener had just somehow been
> entirely broken instead.
The OpenBSD folks may not see it as a bug at all. For us, it's a bug,
because it pointlessly breaks compatibility. No doubt about that.
On Thu, Jun 10, 2010 at 04:38:21PM -0000, Grondr wrote:
> Wait, what? Are you saying that nc -should- accept -p with -l?
Of course. Otherwise it'd be pointlessly incompatible with the old
netcat.
> In other words, that "nc -l -p 1234" is the same thing as "nc -l 1234"
> in OpenBSD nc?
No, it /is/ not. It should be.
> But that wasn't what the manpage seemed to indicate -at all-.
No, because it's not the case now.
> It goes out of its way, in several places, to claim that this isn't
> possible,
It's not. From netcat.c:
if (lflag && pflag)
errx( 1, "cannot use -p and -l");
We should just change that.
> yes, changing this will restore a huge amount of compatibility with
> the traditional nc, and I don't understand why OpenBSD went out of
> their way (in both the code and the manpage) to make this not work in
> the first place.
Well, having to pass -p /is/ kind of silly. If you want to listen, you
want to specify a port on which to do so, so making you pass the -p
*option* only makes sense because of tradition.
> P.S. You say you don't know where I was going w/my comment about compatible change) that that's why I was so
> "broken" vs -l -p. I was simply trying to say that the current (bug?
> deliberate change?) to the behavior of -l -p made it look like nc
> simply couldn't be used as a listener at all, and that, when I wrote
> the report, I hadn't yet discovered that the manpage for the OpenBSD's
> version claimed that -l -p was simply incorrect usage (based on what
> looked like a non-upward-
> intemperate in my tone---until I found what looked like a deliberate
> change in semantics (which you now say is a bug---I agree!), it looked
> like the intended way to use nc as a listener had just somehow been
> entirely broken instead.
The OpenBSD folks may not see it as a bug at all. For us, it's a bug,
because it pointlessly breaks compatibility. No doubt about that.
-- www.ubuntu. com/
Soren Hansen
Ubuntu Developer
http://