On Sun, Jul 21, 2013 at 5:05 AM, Ronald F. Guilmette <r...@tristatelogic.com>wrote:
> > In message <CAGwOe2ZEV3o-= > z1a3pgbtchaehmbqb5fwpx-7emgbtsj7ay...@mail.gmail.com> > =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= <fernando.apesteg...@gmail.com> > wrote: > > >It seems to work for me: > > Good. > > Just to make sure that we are clear, you are simply confirming what my > bug report (bin/176713) said, i.e. that _without_ my fix, nc can > prematurely > truncate the output from some servers, whereas _with_ my fix this bad > behaviour on the part of nc is cured... Is that correct? > Yes, that is what I tested. Behavior before (truncated output) and after (correct output) applying the patch. If this is going to be the final version of the patch, i.e. if it is going to include the -q flag, then the patch needs to be extended to reflect that in nc(1) man page. > > If so, thank you for confirming that my proposed fix produces the > desired result. > > I feel compelled to say again that in actual point of fact, the way that > I personally would prefer to see this problem resolved would *not* be to > add a new option for the nc program. Rather, I think that it would > actually be best simply to delete from the nc source code the one single > line that is causing nc to stop its operation as soon as it receives > an EOF from its stdin channel. If that line is simply deleted, then > nc will instead wait until it receives an EOF from the remote server > that it is talking to, and quite obviously, this change causes nc to > produce output which is arguably more correct and which is certainly > more useful that the prematurely truncated results that nc sometimes > produces at present. > > >> P.P.S. I have just realized that yet one more critical enhancement for > >> nc is called for, and I will be filing a separate and additional PR for > >> that soon. I hope that someone will be able to take a look at that as > >> soon as it is filed. > > > >Just out of curiosity. What is it about? > > Well, as it turns out, the additional "fix" that I had believed that I > was going to propose for nc was not that critical after all... at least > not for my current and immediate application(s). However it might still > have some value in some cases anyway, so I will describe what I had in > mind. > > Quite simply, I believe that it would be Good if the nc program had a > new and additional option which, when used, would cause nc to refrain > from sending any data _to_ the remote server until such time as it had > received one entire line _from_ the remote server. > > Such an option could be useful when using nc to communicate with remote > servers running certain protocols. For example, the rules of the SMTP > protocol... just to name one... require that a client wait until the > server has sent out an initial greeting banner before the client sends > anything to the server. Some SMTP servers are lenient about enforcing > this protocol rule, so in practice it may often not be necessary to wait > for the greeting banner before sending SMTP commands from the client to > the server. However there may perhaps be other instances where waiting > actually is required, and thus I believe that an option to produce that > kind of behavior might be a useful addition to the nc command. > > > Regards, > rfg > _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
