Date: Sun, 21 Jul 2013 19:10:16 -0700 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 Message-ID: <92036.1374459016@server1.tristatelogic.com> In-Reply-To: <CAGwOe2Z%2BcS5zRx4NomiuXb5f04tp5WmKUXw67CQToEzWiHwuwQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?92036.1374459016>