RE: Debug / cut'n'paste on IRIX

RE: Debug / cut'n'paste on IRIX

[Andrej Borsenkow]

> Aha! This sounds the hell like FIONREAD problem (typeahed is lost).
>
> Folks, what happens, when ZSH outputs PS2? What I mean is:
>
> if I simply have typeahead and ZSH returns to PS1, it (if
> configured - my case) explicitly uses FIONREAD to check for
> typeahead before changing tty modes.
>
> Does it do the same for PS2? Does it change tty modes in this
> case? If yes, is it using FIONREAD?
>

that's what happens. I could not find the relevatnt part in sources -
anybody (Geoff) - could you get a look:
This was for

for i in 1 2 3 4 5
do
 bla bla bla
done

Cut'n'pasted in another shell. As you see, after it gets first new line it
does ioctl(10, TCSETSW,...) before PS2, that, unfortunately, throughs away
all pending input :-( The following FIONREAD is useless in this case.

9845:	read(10, " 5", 1)				= 1
9845:	write(10, " 5", 1)				= 1
9845:	read(10, "\n", 1)				= 1
9845:	poll(0x000000FFFFFEC768, 1, 0)			= 1
9845:	write(10, "\r\n", 2)				= 2
9845:	ioctl(10, TCGETA, 0x000000FFFFFEE6E4)		= 0
9845:	ioctl(10, TCSETSW, 0x00000000004C1620)		= 0
9845:	alarm(0)					= 0
9845:	sigaction(SIGINT, 0x000000FFFFFEE528, 0x0000000000000000) = 0
9845:	ioctl(10, FIONREAD, 0x000000FFFFFEE454)		= 0
9845:	ioctl(10, TIOCGSID, 0x000000FFFFFEE394)		= 0
9845:	getsid(0)					= 7682
9845:	ioctl(10, TIOCSPGRP, 0x000000FFFFFEE3DC)	= 0
9845:	ioctl(10, TCGETA, 0x000000FFFFFEE394)		= 0
9845:	ioctl(10, TCSETSW, 0x000000FFFFFEE458)		= 0
9845:	write(10, 0x00000000004BC8C0, 26)		= 26
9845:	  \r1B [ 0 m1B [ 2 2 ; 2 7 m1B [ 2 4 m1B [ J f o r >
9845:	write(10, "1B [ K", 3)				= 3
9845:	read(10, 0x000000FFFFFEE474, 1)	(sleeping...)
9

Re: Debug / cut'n'paste on IRIX

[Geoff Wing]

Andrej Borsenkow <borsenkow.msk@sni.de> typed:
:[I am sorry for all these mails]
:> that's what happens. I could not find the relevant part in
:> sources - anybody (Geoff) - could you get a look:
:>
:> Cut'n'pasted in another shell. As you see, after it gets first
:> new line it does ioctl(10, TCSETSW,...) before PS2, that,
:> unfortunately, throughs away all pending input :-( The following
:> FIONREAD is useless in this case.

There is a problem I have on my machine with nearly every shell
with pasting large amounts into the shell.  At one time I made a
quick aborted effort into searching for it.  I wondered if it was
to do with ungetting characters unsafely but haven't fixed my
thinking as that being the cause for the buffer overwriting.  It needs
a larger amount of data (not, say, < 200 chars as reported in the Irix
case) before I'm likely to see it.  Many other applications don't show
it, e.g.  vim in the shell will work fine.  My normal check here is
select a screen worth into the cut buffer then type "echo '" and paste.
It'll beep at me (several times) and lose most of the stuff.

Anyway, I'll make another look for it soon (i.e. not today).

Regards,
-- 
Geoff Wing   <gcw@pobox.com>            Mobile : (Australia) 0412 162 441
Work URL: http://www.primenet.com.au/   Ego URL: http://pobox.com/~gcw/

Re: Debug / cut'n'paste on IRIX

[Peter Stephenson]

"Andrej Borsenkow" wrote:
> Looks, like it is done in settyinfo(), that is (unconditionally) called from
> trashzle() that is called from zleread() after we've seen new line. (It is
> actually using tcsetattr() on our system)

I haven't been into this in enough detail to propose a definite fix, but
how about something like: set a flag when calling zleread() from the shell
input mechanism (which is where we may need another line) to postpone the
trashzle() --- we can make the last argument take or'd flags.  Then call
trashzle() instead when input processing is really finished: maybe in
hend() would do the trick.  I can believe it's not that simple.

I think you're right that the correct thing to do is something much more
sophisticated anyway.  But I'm not sure what and I'm not convinced it's
ever going to happen.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

RE: Debug / cut'n'paste on IRIX

[Andrej Borsenkow]

[I am sorry for all these mails]

>
> that's what happens. I could not find the relevant part in
> sources - anybody (Geoff) - could you get a look:
>
> Cut'n'pasted in another shell. As you see, after it gets first
> new line it does ioctl(10, TCSETSW,...) before PS2, that,
> unfortunately, throughs away all pending input :-( The following
> FIONREAD is useless in this case.
>


Looks, like it is done in settyinfo(), that is (unconditionally) called from
trashzle() that is called from zleread() after we've seen new line. (It is
actually using tcsetattr() on our system)

Fixing it is probably not trivial. Currently, the only place where FIONREAD
is used is setupterm(). If we find typeahed, we avoid calling sttyinfo() at
all. May be, we should come up with a single function that checks for
typeahead, reads it in buffer and changes tty modes after that?

And I wonder, if this is all ... We already had (still unresolved) case with
read -q ...

/andrej

RE: Debug / cut'n'paste on IRIX

[Andrej Borsenkow]

the code.
>
> Several tries with a normal zsh (full speed) show that even than
> sometime it works just fine but then again it looses some of the input
> when this comes at high speed as is true when it comes via cut'n'paste.
>

Aha! This sounds the hell like FIONREAD problem (typeahed is lost).

Folks, what happens, when ZSH outputs PS2? What I mean is:

if I simply have typeahead and ZSH returns to PS1, it (if configured - my
case) explicitly uses FIONREAD to check for typeahead before changing tty
modes.

Does it do the same for PS2? Does it change tty modes in this case? If yes,
is it using FIONREAD?

cheers

/andrej

Re: Debug / cut'n'paste on IRIX

[Helmut Jarausch]

Thanks to all for your hints on debugging ZSH. It worked great.

Still, as every real bug, it didn't show up when stepping slowly through
the code.

Several tries with a normal zsh (full speed) show that even than
sometime it works just fine but then again it looses some of the input
when this comes at high speed as is true when it comes via cut'n'paste.

So, it looks to me like an 'overrun' but on an XTerm which should be
really fast.

Unfortunately I have no idea about the technicalities of terminal I/O
so I have to give up.

Sorry for the bad news,
Helmut.