zsh-workers
 help / color / mirror / code / Atom feed
* tcp_read -d and newlines
@ 2009-04-05 23:10 Clint Adams
  2009-04-06  8:59 ` Peter Stephenson
  0 siblings, 1 reply; 4+ messages in thread
From: Clint Adams @ 2009-04-05 23:10 UTC (permalink / raw)
  To: zsh-workers

When tcp_read -d'ing a socket that doesn't end in a newline, the last "line" gets discarded,
I think, because read returns an error on that line.  What can be done?


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: tcp_read -d and newlines
  2009-04-05 23:10 tcp_read -d and newlines Clint Adams
@ 2009-04-06  8:59 ` Peter Stephenson
  2009-04-06  9:10   ` Peter Stephenson
  2009-04-07 18:01   ` Clint Adams
  0 siblings, 2 replies; 4+ messages in thread
From: Peter Stephenson @ 2009-04-06  8:59 UTC (permalink / raw)
  To: zsh-workers

On Sun, 5 Apr 2009 23:10:36 +0000
Clint Adams <clint@zsh.org> wrote:
> When tcp_read -d'ing a socket that doesn't end in a newline, the last
> "line" gets discarded,  I think, because read returns an error on that
> line.

I've had problems with this, too, in the past, although I think my problem
was chunks of input (not necessarily ending in EOF) that didn't have
newlines.  I could find an easy way of handling this.  It sounds like your
problem is when there is an EOF.

> What can be done? 

One possible but slightly clumsy mechanism is to introduce a flag, say -D,
that allows an incomplete line but returns something different if there's
no delimiter (e.g. it sets REPLY2 to the delimiter actually read which may
be empty, and I suppose we could allow it to be the EOF character too).
It's clumsy because if you want to fix my case you have to poll for input,
and we've found in the past that doing this correctly on terminals can be a
black art (terminals aren't the problem here but it's up to us to disguise
the type of input as much as possible since it's not fair to tell shell
users it's all termios' fault).  If we plan on getting an EOF it's
relatively straightforward.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: tcp_read -d and newlines
  2009-04-06  8:59 ` Peter Stephenson
@ 2009-04-06  9:10   ` Peter Stephenson
  2009-04-07 18:01   ` Clint Adams
  1 sibling, 0 replies; 4+ messages in thread
From: Peter Stephenson @ 2009-04-06  9:10 UTC (permalink / raw)
  To: zsh-workers

On Mon, 6 Apr 2009 09:59:01 +0100
Peter Stephenson <pws@csr.com> wrote:
> On Sun, 5 Apr 2009 23:10:36 +0000
> Clint Adams <clint@zsh.org> wrote:
> > When tcp_read -d'ing a socket that doesn't end in a newline, the last
> > "line" gets discarded,  I think, because read returns an error on that
> > line.
> 
> I've had problems with this, too, in the past, although I think my problem
> was chunks of input (not necessarily ending in EOF) that didn't have
> newlines.  I could find an easy way of handling this.
                    \
                     n't, sorry.  Probably obvious from the context but I
		     thought I'd better correct it.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: tcp_read -d and newlines
  2009-04-06  8:59 ` Peter Stephenson
  2009-04-06  9:10   ` Peter Stephenson
@ 2009-04-07 18:01   ` Clint Adams
  1 sibling, 0 replies; 4+ messages in thread
From: Clint Adams @ 2009-04-07 18:01 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: zsh-workers

On Mon, Apr 06, 2009 at 09:59:01AM +0100, Peter Stephenson wrote:
> I've had problems with this, too, in the past, although I think my problem
> was chunks of input (not necessarily ending in EOF) that didn't have
> newlines.  I could find an easy way of handling this.  It sounds like your
> problem is when there is an EOF.

Yes, I've had some mysteriously loss before but in this case I was
definitely able to confirm that the transmission ended in not-a-newline.
read processes the data, but returns an error so tcp_read tosses it.

I don't actually need the input broken up into lines, so maybe I should
be doing this differently.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-04-07 18:02 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-05 23:10 tcp_read -d and newlines Clint Adams
2009-04-06  8:59 ` Peter Stephenson
2009-04-06  9:10   ` Peter Stephenson
2009-04-07 18:01   ` Clint Adams

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).