RE: Debug / cut'n'paste on IRIX

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

[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

PATCH: 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)

OK, here's my first attempt.  Unfortunately I can't test whether this fixes
the bug, since I don't have it.  However, so far it hasn't blown anything
else.  The only way to see if it does is by testing, so it will appear in
pws-12 and I'll wait for expostulations.

What now happens is that zleread() doesn't restore the tty when called in
the normal run of things from the main input routine, since that may want
more input, as in the case that caused the bug.  Instead, the
end-of-history (that sounds rather alarming) routine is made responsible
for putting the terminal back.  I've tried to arrange it so other calls to
trashzle() and zleread() do what they always did, which is why there are
three sets of flags --- one to zleread(), one to get hend() to restore the
terminal, one static flag between zleread() and trashzle().  I could
probably have made fewer changes, but it would have had possible side
effects such as the terminal not being restored when zle was temporarily
interrupted (e.g. by a background job exiting).

Now I'll probably find it doesn't fix the bug.

If it does work, it's a candidate for porting to 3.0.6.

--- Src/Zle/zle_main.c.trash	Mon Mar  1 10:35:34 1999
+++ Src/Zle/zle_main.c	Fri Mar 12 14:33:22 1999
@@ -394,11 +394,13 @@
     return ret;
 }
 
+static int no_restore_tty;
+
 /* Read a line.  It is returned metafied. */
 
 /**/
 unsigned char *
-zleread(char *lp, char *rp, int ha)
+zleread(char *lp, char *rp, int flags)
 {
     unsigned char *s;
     int old_errno = errno;
@@ -451,7 +453,7 @@
     pmpt_attr = txtchange;
     rpromptbuf = promptexpand(rp, 1, NULL, NULL);
     rpmpt_attr = txtchange;
-    histallowed = ha;
+    histallowed = (flags & ZLRF_HISTORY);
     PERMALLOC {
 	histline = curhist;
 #ifdef HAVE_SELECT
@@ -486,6 +488,8 @@
 	if (tmout)
 	    alarm(tmout);
 	zleactive = 1;
+	if (flags & ZLRF_NOSETTY)
+	  no_restore_tty = 1;
 	resetneeded = 1;
 	errflag = retflag = 0;
 	lastcol = -1;
@@ -535,7 +539,7 @@
 	trashzle();
 	free(lpromptbuf);
 	free(rpromptbuf);
-	zleactive = 0;
+	zleactive = no_restore_tty = 0;
 	alarm(0);
     } LASTALLOC;
     zsfree(curhistline);
@@ -754,7 +758,7 @@
     PERMALLOC {
 	pushnode(bufstack, ztrdup(s));
     } LASTALLOC;
-    t = (char *) zleread(p1, p2, ops['h']);
+    t = (char *) zleread(p1, p2, ops['h'] ? ZLRF_HISTORY : 0);
     if (!t || errflag) {
 	/* error in editing */
 	errflag = 0;
@@ -885,7 +889,8 @@
 	    fprintf(shout, "%s", postedit);
 	fflush(shout);
 	resetneeded = 1;
-	settyinfo(&shttyinfo);
+	if (!no_restore_tty)
+	  settyinfo(&shttyinfo);
     }
     if (errflag)
 	kungetct = 0;
--- Src/hist.c.trash	Fri Mar 12 13:56:08 1999
+++ Src/hist.c	Fri Mar 12 14:53:25 1999
@@ -735,6 +735,8 @@
     int flag, save = 1;
 
     DPUTS(!chline, "BUG: chline is NULL in hend()");
+    if (histdone & HISTFLAG_SETTY)
+	settyinfo(&shttyinfo);
     if (histactive & (HA_NOSTORE|HA_NOINC)) {
 	zfree(chline, hlinesz);
 	zfree(chwords, chwordlen*sizeof(short));
--- Src/input.c.trash	Fri Mar 12 13:56:27 1999
+++ Src/input.c	Fri Mar 12 14:47:05 1999
@@ -249,8 +249,21 @@
 	    free(pptbuf);
 	}
 	ingetcline = shingetline();
-    } else
-	ingetcline = (char *)zleread(ingetcpmptl, ingetcpmptr, 1);
+    } else {
+	/*
+	 * Since we may have to read multiple lines before getting
+	 * a complete piece of input, we tell zle not to restore the
+	 * original tty settings after reading each chunk.  Instead,
+	 * this is done when the history mechanism for the current input
+	 * terminates, which is not until we have the whole input.
+	 * This is supposed to minimise problems on systems that clobber
+	 * typeahead when the terminal settings are altered.
+	 *                     pws 1998/03/12
+	 */
+	ingetcline = (char *)zleread(ingetcpmptl, ingetcpmptr,
+				     ZLRF_HISTORY|ZLRF_NOSETTY);
+	histdone |= HISTFLAG_SETTY;
+    }
     if (!ingetcline) {
 	return lexstop = 1;
     }
--- Src/zsh.h.trash	Fri Mar 12 13:55:43 1999
+++ Src/zsh.h	Fri Mar 12 13:59:37 1999
@@ -1013,7 +1013,7 @@
 #define HISTFLAG_DONE   1
 #define HISTFLAG_NOEXEC 2
 #define HISTFLAG_RECALL 4
-
+#define HISTFLAG_SETTY  8
 
 /******************************************/
 /* Definitions for programable completion */
@@ -1402,6 +1402,13 @@
 #define ZSIG_TRAPPED	(1<<0)
 #define ZSIG_IGNORED	(1<<1)
 #define ZSIG_FUNC	(1<<2)
+
+/**********************************/
+/* Flags to third argument of zle */
+/**********************************/
+
+#define ZLRF_HISTORY	0x01
+#define ZLRF_NOSETTY	0x02
 
 /****************/
 /* Entry points */

-- 
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: PATCH: cut'n'paste on IRIX

[Andrej Borsenkow]

>
> Now I'll probably find it doesn't fix the bug.
>
> If it does work, it's a candidate for porting to 3.0.6.
>

This works for me. Thanks.

The only problem is, we have to set CLOBBERS_TYPEAHED. Last time I checked
it was set for me :-), Ultrix and something else - but definitely not for
Irix. So, either we have different problem on Irix, or Irix should set
CLOBBERS_TYPEAHED.

Thinking about it: writing general configure test requires spawning a child
connected to pty. Unforunately, there are too many ways to create a pty to
make such test useful.

Another approach is to simply always use FIONREAD if available. What is the
point of setting magical CLOBBERS_TYPEAHEAD at all?

/andrej

PATCH: 3.1.5-pws-12: configuration changes

[Peter Stephenson]

"Andrej Borsenkow" wrote:
> This works for me. Thanks.

Satisfied customer, as Basil Fawlty said.

> The only problem is, we have to set CLOBBERS_TYPEAHED. Last time I checked
> it was set for me :-), Ultrix and something else - but definitely not for
> Irix. So, either we have different problem on Irix, or Irix should set
> CLOBBERS_TYPEAHED.

Well, the following sets it for Irix.  I'm only using Irix 6.2 and only
(very) remotely, and I didn't see the bug, but I've reconfigured to check
this doesn't do anything obviously wrong.  Helmut, you'll probably need
this.

> Another approach is to simply always use FIONREAD if available. What is the
> point of setting magical CLOBBERS_TYPEAHEAD at all?

In my case, fear.  But given that the mechanism we have seems to work
seamlessly when it's required, there's certainly an argument for removing
the test.

I also rescued Reliant UNIX and Rhapsody (see 4594) from the old
config.guess.

--- config.guess.irix	Mon Mar 15 10:26:14 1999
+++ config.guess	Mon Mar 15 09:52:44 1999
@@ -767,6 +767,9 @@
     RM*:SINIX-*:*:*)
 	echo mips-sni-sysv4
 	exit 0 ;;
+    RM*:ReliantUNIX-*:*:*)
+       echo mips-sni-sysv4
+       exit 0 ;;
     *:SINIX-*:*:*)
 	if uname -p 2>/dev/null >/dev/null ; then
 		UNAME_MACHINE=`(uname -p) 2>/dev/null`
@@ -800,6 +803,12 @@
 	else
 	        echo mips-unknown-sysv${UNAME_RELEASE}
 	fi
+        exit 0 ;;
+    Power*:Rhapsody:*:*)
+        echo powerpc-apple-rhapsody${UNAME_RELEASE}
+        exit 0 ;;
+    *:Rhapsody:*:*)
+        echo ${UNAME_MACHINE}-apple-rhapsody${UNAME_RELEASE}
         exit 0 ;;
     BeBox:BeOS:*:*)	# BeOS running on hardware made by Be, PPC only.
 	echo powerpc-be-beos
--- configure.in.irix	Sat Mar 13 14:46:44 1999
+++ configure.in	Mon Mar 15 09:57:52 1999
@@ -893,7 +893,7 @@
 dnl The doubled square brackets are necessary because autoconf uses m4.
 AC_CACHE_CHECK(if typeahead needs FIONREAD, zsh_cv_sys_clobbers_typeahead,
 [case x-$host_vendor-$host_os in
-    x-*-ultrix* | x-*-dgux* | x-sni-sysv4*)
+    x-*-ultrix* | x-*-dgux* | x-sni-sysv4* | x-*-irix*)
 	zsh_cv_sys_clobbers_typeahead=yes;;
     *)
 	zsh_cv_sys_clobbers_typeahead=no;;

-- 
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

[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/

up-line-or-history and multiline input (was: RE: Debug / cut'n'paste on IRIX)

[Andrej Borsenkow]

I have a feeling, that these two are related ...

Look at this (zsh-3.1.5-pws-12):

bor@itsrm2:~%> for i in 1 2 3 4
for> do
for><up-line-or-history>
   gives
bor@itsrm2:~%> for i in 1 2 3 4
for> do
for> setopt completeinword

That is, when working with multiline input _every_ line is considered the
"first and only" line of input by ZLE.

I find it (and always found) very confusing. Even more, as you can go to
previous line by using backward-char

It is confusing, because when I recall the whole buffer, I *can* use
up-line-or-history as expected.

And it is related to multiline paste because if we treated the input as
multiline, there would probably be no need to call trashzle at all ...

cheers

/andrej