* RE: Debug / cut'n'paste on IRIX
@ 1999-03-12 10:21 Andrej Borsenkow
1999-03-12 10:34 ` Peter Stephenson
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Andrej Borsenkow @ 1999-03-12 10:21 UTC (permalink / raw)
To: Helmut Jarausch, zsh-workers
[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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Debug / cut'n'paste on IRIX 1999-03-12 10:21 Debug / cut'n'paste on IRIX Andrej Borsenkow @ 1999-03-12 10:34 ` Peter Stephenson 1999-03-12 14:02 ` PATCH: " Peter Stephenson 1999-03-12 14:33 ` Debug / cut'n'paste on IRIX Geoff Wing 2 siblings, 0 replies; 7+ messages in thread From: Peter Stephenson @ 1999-03-12 10:34 UTC (permalink / raw) To: zsh-workers "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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* PATCH: cut'n'paste on IRIX 1999-03-12 10:21 Debug / cut'n'paste on IRIX Andrej Borsenkow 1999-03-12 10:34 ` Peter Stephenson @ 1999-03-12 14:02 ` Peter Stephenson 1999-03-15 8:19 ` Andrej Borsenkow 1999-03-12 14:33 ` Debug / cut'n'paste on IRIX Geoff Wing 2 siblings, 1 reply; 7+ messages in thread From: Peter Stephenson @ 1999-03-12 14:02 UTC (permalink / raw) To: zsh-workers "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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: PATCH: cut'n'paste on IRIX 1999-03-12 14:02 ` PATCH: " Peter Stephenson @ 1999-03-15 8:19 ` Andrej Borsenkow 1999-03-15 9:38 ` PATCH: 3.1.5-pws-12: configuration changes Peter Stephenson 0 siblings, 1 reply; 7+ messages in thread From: Andrej Borsenkow @ 1999-03-15 8:19 UTC (permalink / raw) To: Peter Stephenson, zsh-workers > > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* PATCH: 3.1.5-pws-12: configuration changes 1999-03-15 8:19 ` Andrej Borsenkow @ 1999-03-15 9:38 ` Peter Stephenson 0 siblings, 0 replies; 7+ messages in thread From: Peter Stephenson @ 1999-03-15 9:38 UTC (permalink / raw) To: zsh-workers "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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Debug / cut'n'paste on IRIX 1999-03-12 10:21 Debug / cut'n'paste on IRIX Andrej Borsenkow 1999-03-12 10:34 ` Peter Stephenson 1999-03-12 14:02 ` PATCH: " Peter Stephenson @ 1999-03-12 14:33 ` Geoff Wing 1999-03-15 9:31 ` up-line-or-history and multiline input (was: RE: Debug / cut'n'paste on IRIX) Andrej Borsenkow 2 siblings, 1 reply; 7+ messages in thread From: Geoff Wing @ 1999-03-12 14:33 UTC (permalink / raw) To: zsh-workers 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* up-line-or-history and multiline input (was: RE: Debug / cut'n'paste on IRIX) 1999-03-12 14:33 ` Debug / cut'n'paste on IRIX Geoff Wing @ 1999-03-15 9:31 ` Andrej Borsenkow 0 siblings, 0 replies; 7+ messages in thread From: Andrej Borsenkow @ 1999-03-15 9:31 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~1999-03-15 9:56 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-03-12 10:21 Debug / cut'n'paste on IRIX Andrej Borsenkow 1999-03-12 10:34 ` Peter Stephenson 1999-03-12 14:02 ` PATCH: " Peter Stephenson 1999-03-15 8:19 ` Andrej Borsenkow 1999-03-15 9:38 ` PATCH: 3.1.5-pws-12: configuration changes Peter Stephenson 1999-03-12 14:33 ` Debug / cut'n'paste on IRIX Geoff Wing 1999-03-15 9:31 ` up-line-or-history and multiline input (was: RE: Debug / cut'n'paste on IRIX) Andrej Borsenkow
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).