> >> Yes, but it would even be better if there would be an option to get > >> the shutdown on EOF behaviour back. > >> > >> Some servers wait until they see the shutdown from the client to finish > >> their work. > > woah. Can somebody explain, using very small words, exactly what the > problem is?
Once upon a time, there was a bug. It haunted people across systems for more than ten years, and people have invented workarounds in fear someone actually depend on the bug. That is apparently the "some servers" otto is talking about. I haven't seen any yet, but some bugs can arise because people are using nc(1) in their scripts. Now the bug is gone and there are many opinions about what to do. I wanted to kill it and tell people to fix their software from now on. That obviously isn't acceptable if the whole world has adopted the earlier behavior *and* if this would cause more harm than good. > From reading the ubuntu bug report, their problem comes from adding a > -q flag very similar to the proposed -N flag, and *that's* what broke. > Unmodified netcat does not have whatever bug they're talking about. Unmodified netcat terminates the wrong socket prematurely (on stdin EOF). That's the problem. Some people decided to do their own actions without bothering to inform upstream. If someone is commenting on a bug with an option *they* added, it's *their* problem. Until I see a real reason why their -q is needed here, I'm against. *Our* problem is people might depend on what -N does. Otto mentioned that and proposed -N. > For that matter, if this is a real problem, why are we using -N and > not -q? This seems like a wholly gratuitous difference for no benefit. Because it does two different things. -N preserves the old buggy behavior and -q does (according to their man page) waiting in seconds. What does 'q' stand for anyway? -- Martin Pelikan
