Changed my mind about the EOF policy in SSH mode: I think the SSH
authorsimon <simon@cda61777-01e9-0310-a592-d414129be87e>
Tue, 13 Sep 2011 15:38:12 +0000 (15:38 +0000)
committersimon <simon@cda61777-01e9-0310-a592-d414129be87e>
Tue, 13 Sep 2011 15:38:12 +0000 (15:38 +0000)
commit4a202fc69e12e9699cd79de9f6457506c663bc07
treed58b3894d647ef9f4b38aab4f1b112018feb1756
parent997097db8b9bd66341290cda4effcd93fa74e4d0
Changed my mind about the EOF policy in SSH mode: I think the SSH
backend should unilaterally assume outgoing EOF when it sees incoming
EOF, if and only if the main session channel is talking to a pty.
(Because ptys don't have a strong concept of EOF in the first place,
that seems like a sensible place to draw the line.) This fixes a bug
introduced by today's revamp in which if you used Unix Plink to run a
console session it would hang after you hit ^D - because the server
had sent EOF, but it was waiting for a client-side EOF too.

git-svn-id: svn://svn.tartarus.org/sgt/putty@9282 cda61777-01e9-0310-a592-d414129be87e
ssh.c