I'll try one more time to make the point I'm trying to make, and then I'll give up until someone who seems to understand it chimes in. (And by the way, calling a usability complaint "flamebait" isn't exactly setting the right tone yourself.)
100% of my usage of nc is in building tunnels. 50% of nc's invocations are thus listeners, and 50% are senders. 100% of listeners require (in the old nc) specifying both -l and -p. Since OpenBSD apparently decided to take what seems to me the case that is -required- in -every- usage of nc for this purpose and incompatibly break it (not -just- by dropping -p's original meaning---which at least would mean it wouldn't show up in a usage messsage---but by making it mean something -completely different- while -simultaneously- making it fail when used with -l!), this means that anyone expecting the traditional nc (which is not only something like 20 years old, but has also been shipping by default in Ubuntu as long as Ubuntu has been around---until now) will be screwed by the change in behavior. So it really doesn't matter how many -other- options -haven't- been changed---they picked the -one- option I use -every single time- and made the same option mean something completely different, in a way guaranteed to cause the program to (apparently inexplicably) fall over and emit a usage message instead. You complain that I called it "broken", but it wasn't until after I posted my first entry in this that I even -realized- that the currently- default nc -did not allow- both -l and -p in the same command line! It just never even crossed my mind that the old nc would have been replaced with one that didn't take the same command line args in an upward- compatible fashion, but instead decided to just break if called with the old ones. So yes, when I first posted, I truly believed that nc was absolutely, completely broken, because I could not come up with a single command line that failed to do anything but emit a usage message. When I've been using the same program for decades and it suddenly won't take the same commands I've been giving it all that time, my first inclination is -not- to turn to a manpage to see if someone has scrambled the allowed options---especially when I see in the usage it spits out that the only options I was trying (-l and -p) -were- still there. Suuuure, if I'd really read it carefully, I'd have seen "source" at -p and said, "Eh?", but even that might not have necessarily been enough to raise a big red flag. So yeah, when I wrote that report, I honestly believed that Ubuntu had shipped a completely broken netcat---one that, despite my best efforts, could not be made into a listener. I just couldn't believe it. It seemed incomprehensible that their quality control had fallen so far that they could (a) modify and (b) -break- such a fundamental part of netcat. As I see it, there's plenty of blame to go around: (a) OpenBSD, for breaking the established argline for no particularly good reason. (b) Ubuntu, for substituting in their version without making some changes (like making it -really clear- from the usage that this isn't the nc you were expecting, e.g., by altering the usage message or applying pressure upstream to do so), or perhaps offering -both- as nc and nc.openbsd or something---at least the latter would have been entirely upward-compatible with scripts and usage that -did work- under prior Ubuntu releases, unlike the current behavior. (c) OpenBSD again, for doing such a piss-poor job of options parsing that, instead of actually telling you -why- it's rejecting what you tried, it just blats out a generic usage message---if it's supposedly so improved, then why is the argument parsing so lame? -Especially- if they're going to incompatibly change such a common option as -p, they should have gone the extra mile and been very clear about what was going on---maybe not in every possible case, but c'mon, it's the first thing any traditional nc user is going to trip over, so seeing both -l and -p in the same command line should probably be special-cased into saying, "This is OpenBSD's version of netcat, which has incompatibly changed the meaning of -p, which no longer means which port to listen on. Please see the following usage" or something like that. Unless Ubuntu can successfully apply backpressure upstream (I'd have said, "We won't make OpenBSD's version of nc the default until the following fake-out usability issues are addressed"), then I'd say this is a bug in Ubuntu usability (no idea where to file -that- bug) because they accepted OpenBSD's redefinition of nc's args without complaint and without warning their installed base---perhaps by patching nc.openbsd downstream to issue that warning. Ubuntu certainly isn't shy about making their own downstream patches in other things---this seems like an issue that begs for it. As for filing a feature request with OpenBSD for better and clearer version/origin info, I can try it, but I'm fairly sure the OpenBSD crowd will just say, "We've been using this for years and it's -our- program, so why should -we- be the ones to include something that points out it's from OpenBSD?" They might object that it's Ubuntu's job (or maybe Debian's---I don't know who made this change) to make it clear, since U/D are the ones who decided to -switch-, after years of the traditional nc, to using OpenBSD's version in the first place. And as for the original nc, it so happens I've been friends with its author for almost 30 years. I'll mention it to him the next time I see him. OTOH, he -always- writes kinda hackish code when it comes to interfaces, so it's only slightly likely he'd want to put in GNU-style arg parsing---and might again say, given that nc's been basically unchanged for so long, that there didn't seem to be much point in changing such a venerable codebase. -- broken version of netcat installed by default https://bugs.launchpad.net/bugs/590925 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
