Re: ncat 5.10BETA handling of -l -p is not compatible with nc-1.10

[Denys Vlasenko <vda.linux () googlemail com>]

On Friday 08 January 2010 22:33, Fyodor wrote:
> On Fri, Jan 08, 2010 at 05:32:00PM +0100, Denys Vlasenko wrote:
> > Every reimplementation of netcat seems to try to break
> > this syntax:
> >
> > nc -l -p 123    # listen on local port 123
> >
> > GNU nc, openbsd's nc all have it broken. And ncat is no exception.
> > "You too, Brutus". IIRC they even break it in different ways -
> > they have different ways to specify local port: as a parameter
> > to -l option, as a standalone port parameter etc... AARRGGHH...
> >
> > This makes users' lives harder for no apparent benefit.
>
> One difference between ncat and those other reimplementations is that
> we don't use the name "nc".  So you can have both installed at once,
> and if you specifically request "ncat", then you know what syntax
> you're going to get.

I heard that Fedora plans to ditch openbsd's implementation of nc
and use ncat. They are going to rename it to nc (otherwise scripts
which use nc would break).

> I think our syntax for listening on port 123 
> ("ncat -l 123") is preferable to the longer "nc -l -p 123".

Because it is shorter by 3 chars? Such insignificant
advantage is not going to amuse people who would need
to jump through hoops in their scripts (checking
"nc --version" and such) just in order to open a listening
socket.

Do you understand why compatibility is important?

> And as 
> David noted, we do give an error message which explains the problem if
> you try to use -p with -l.

That is not helpful in the scripts.

> That being said, I also agree with David that it would be reasonable
> for us to just "do what the user wants" in the -l -p case.  At least
> as long as the code change is simple.  I think a warning message would
> still be warranted, at least in verbose mode.

What's wrong with simply keeping compatibility with original nc?
What are the drawbacks?

--
vda
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/