From owner-freebsd-hackers@FreeBSD.ORG  Mon Jul 22 02:10:16 2013
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by hub.freebsd.org (Postfix) with ESMTP id C005FEDF
 for <freebsd-hackers@freebsd.org>; Mon, 22 Jul 2013 02:10:16 +0000 (UTC)
 (envelope-from rfg@tristatelogic.com)
Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com
 [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id A181B1CC2
 for <freebsd-hackers@freebsd.org>; Mon, 22 Jul 2013 02:10:16 +0000 (UTC)
Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1])
 by segfault.tristatelogic.com (Postfix) with ESMTP id 11B233B604
 for <freebsd-hackers@freebsd.org>; Sun, 21 Jul 2013 19:10:16 -0700 (PDT)
From: "Ronald F. Guilmette" <rfg@tristatelogic.com>
To: FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon
In-Reply-To: <CAGwOe2Z+cS5zRx4NomiuXb5f04tp5WmKUXw67CQToEzWiHwuwQ@mail.gmail.com>
Date: Sun, 21 Jul 2013 19:10:16 -0700
Message-ID: <92036.1374459016@server1.tristatelogic.com>
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2013 02:10:16 -0000


In message <CAGwOe2Z+cS5zRx4NomiuXb5f04tp5WmKUXw67CQToEzWiHwuwQ@mail.gmail.com>
=?ISO-8859-1?Q?Fernando_Apestegu=EDa?= <fernando.apesteguia@gmail.com> wrote:

>Yes, that is what I tested. Behavior before (truncated output) and after
>(correct output) applying the patch.

OK, good.  Thanks.

>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.

I am in complete agreement that _if_ a new option is implemented within nc
then it really must also be properly documented in the associated man page.

As I have expressed however, it is my hope that whoever decides these
things will decide to simply fix the bug in nc and to _not_ even bother
to introduce an option which might help to preserve ``backward compatability''
with the current (broken) behavior of nc.

I simply do not believe that the current (arguably "broken") behavior of nc
is of any particular value to anybody.  The only reason I proposed a patch
that included an option to elicit the (non-broken) behavior was because I
have the humility to admit that I am not actually omniscient with respect
to other people's needs.


Regards,
rfg