bin/176713: [patch] nc(1) closes network socket too soon

[Ronald F. Guilmette]

In message <CAGwOe2ZEV3o-=Z1A3PgBtChAEhMbqB5fwPx-7emGbTSJ7AyMPA at mail.gmail.com>
=?ISO-8859-1?Q?Fernando_Apestegu=EDa?= <fernando.apesteguia at 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?

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