In message <1375112533.45247.43.ca...@revolution.hippie.lan>,
Ian Lepore wrote:
>I don't think this accurately summarizes things...
Everyone is entitled to her or her own opinion.
Unfortunately, due to other pressing matters I will no longer be able
to be an active participant in this debate.
On Tue, 2013-07-23 at 16:48 -0700, Ronald F. Guilmette wrote:
> In message
>
> Adrian Chadd wrote:
>
> >Right, and your patch just stops the shutdown(), right?
>
> The shutdown that occurs when EOF is encountered on stdin, yes.
>
> >Rather than
> >teaching nc to correctly check BOTH socket st
On 24 July 2013 16:43, Ronald F. Guilmette wrote:
>
> Thank you.
>
> Please consider yourself bugged.
> (1/2 :-)
:-)
I'm currently trying to figure out ixgbe and lagg bugs (separately and
together.) Once I've done that, I'll look at nc. Just keep bugging me
until I do.
-adrian
___
In message
, you wrote:
>Hi,
>
>Well, I've done this before. More than once. I'm glad that you've
>stuck through helping me understand what nc is doing; I'm
>unfortunately busy doing other things
>
>What you end up doing is:
>
>* tracking the state of the two sockets, both for read EOF and write
Hi,
Well, I've done this before. More than once. I'm glad that you've
stuck through helping me understand what nc is doing; I'm
unfortunately busy doing other things
What you end up doing is:
* tracking the state of the two sockets, both for read EOF and write EOF;
* whenever you get an EOF from
In message
Adrian Chadd wrote:
>Right, and your patch just stops the shutdown(), right?
The shutdown that occurs when EOF is encountered on stdin, yes.
>Rather than
>teaching nc to correctly check BOTH socket states before deciding to
>close things.
In effect, nc *is* currently "checking bot
Right, and your patch just stops the shutdown(), right? Rather than
teaching nc to correctly check BOTH socket states before deciding to
close things.
I'd personally rather see nc taught to check to see whether it can
possibly make ANY more progress before deciding to shut things down.
-adrian
In message
Adrian Chadd wrote:
>Right. Yes, I had a typo. I meant that it shouldn't die on seeing a
>read EOF after closing the write side of the socket.
>
>So, what you're saying is:
>
>* nc sees EOF on stdin
Yes.
>* nc decides to abort before seeing the rest of the data come in from
>the re
Right. Yes, I had a typo. I meant that it shouldn't die on seeing a
read EOF after closing the write side of the socket.
So, what you're saying is:
* nc sees EOF on stdin
* nc decides to abort before seeing the rest of the data come in from
the remote socket (and then trying to write it, and abor
In message
Adrian Chadd wrote:
> On 21 July 2013 19:02, Ronald F. Guilmette wrote:
>
>> It has been some time now since I filed my PR but I think that the bottom
>> line is that you need to look at the code (of nc) to understand how it is
>> reacting to EOF on stdin.
>
>Gah, I was kinda hoping
On 21 July 2013 19:02, Ronald F. Guilmette wrote:
> It has been some time now since I filed my PR but I think that the bottom
> line is that you need to look at the code (of nc) to understand how it is
> reacting to EOF on stdin.
Gah, I was kinda hoping not to look at nc, and just work with som
In message
=?ISO-8859-1?Q?Fernando_Apestegu=EDa?= 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
In message
Adrian Chadd wrote:
>Wait a second. What's going on under the hood?
>
>You _should_ be able to shutdown the write side of the socket and have
>it not affect reading.
It has been some time now since I filed my PR but I think that the bottom
line is that you need to look at the code (
In message <20130721041338.2121.qm...@f5-external.bushwire.net>,
"Mark Delany" wrote:
>> 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 cl
On Sun, Jul 21, 2013 at 5:05 AM, Ronald F. Guilmette
wrote:
>
> In message z1a3pgbtchaehmbqb5fwpx-7emgbtsj7ay...@mail.gmail.com>
> =?ISO-8859-1?Q?Fernando_Apestegu=EDa?=
> wrote:
>
> >It seems to work for me:
>
> Good.
>
> Just to make sure that we are clear, you are simply confirming what my
>
Wait a second. What's going on under the hood?
You _should_ be able to shutdown the write side of the socket and have
it not affect reading. It's a broken server if it does a read(), find
that the socket is returning EOF, and then not waiting for the write()
to fail before closing.
If that's actu
> 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 pr
In message
=?ISO-8859-1?Q?Fernando_Apestegu=EDa?= 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
On Sat, Jul 20, 2013 at 4:31 PM, Ronald F. Guilmette
wrote:
>
>
> Could someone please take a look at this bug report (bin/176713) and
> also at the simple patch that I provided to fix the problem?
>
> This is quite a serious problem, and my PR has been pending with no
> action since Wed, 6 Mar 20
Could someone please take a look at this bug report (bin/176713) and
also at the simple patch that I provided to fix the problem?
This is quite a serious problem, and my PR has been pending with no
action since Wed, 6 Mar 2013.
Regards,
rfg
P.S. Please note that in reality, I do not believe
20 matches
Mail list logo
