Re: read -s doesn't work with -t?

Re: read -s doesn't work with -t?

[Peter Stephenson]

(I've moved this to zsh-workers since this is involved enough
even for developers.)

On Sat, 16 Feb 2008 09:37:53 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> It also seems to me that canonical input mode should be set and the
> prompt should be printed before the read-timeout poll is done, so -d
> should come before -t as well.  However, I'm not really sure what's
> going on with shttyinfo versus saveti, so I'm not going to commit the
> following until somebody else checks it over.

It's not obvious to me quite what the difference is, and I suspect that
if bin_read() hadn't grown quite so organically (this is not a term of
approbation) it would me more obvious that they could be combined.

I suspect it's just the fact that the -s and -d code has been written
differently from the -k code.  The latter assumes it's a good idea to
keep the normal shell state (shttyinfo) in sync; this is complicated by
the fact that in non-interactive usage we have to set up shttyinfo if it
wasn't already.  The former assumes it should just alter the current
settings and restore them to what they were afterwards.  The whole thing
is further complicated by the fact that we (I've certainly mucked
around with it, too) do different things depending on additional options
to -k.  This is just a hypothesis.

To be honest, I can't really follow all the ins and outs and if your
patch works (checking -k in combination with other options is probably
the key) it's probably good enough and we can see if problems turn up as
time passes.

It would be nice to have tests but they're particularly difficult to
write for this.

> And of course there may be some kind of bad interaction between changing
> the tty state and reading typeahead that I'm not aware of that makes all
> this impossible, in which case it should just be documented that you
> can't use a prompt or -s or -d in combination with -t.

With a bit of luck, weird interactions of this kind may be just a bad
memory now... I've a vague memory Ultrix came into it.  I don't think we
ever deliberately attempted to handle this outside zle, in any case, but
I could be wrong.  Certainly the word "typeahead", with or without
a hyphen, only seems to occur in Zle (and input.c where we're about
to call Zle.)

> That thread just sort of died without resolution because PWS can't
> reproduce the problem.

I suspect that was more to do with the fact that the xterm stuff wasn't
doing the right thing for me rather than that the shell *was* doing the
right thing, but I never really got to the bottom of it.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: read -s doesn't work with -t?

[Bart Schaefer]

On Feb 17,  5:22pm, Peter Stephenson wrote:
}
} To be honest, I can't really follow all the ins and outs and if your
} patch works (checking -k in combination with other options is probably
} the key) it's probably good enough and we can see if problems turn up as
} time passes.
 
Does it even make sense to use -d and -k at the same time?  I know it
doesn't throw an error to use both (perhaps it should) but the loop
for -k doesn't recognize delimiters (or backslashes -- perhaps the doc
should say that -k implies -r ...?).

In any case I've tested this (use of "-rk" apparently redundant):

	read -st 2 -rk 3 esc$'?\e['"${seq}"t

And these:

	read -srd $'\e'
	IFS=';' read -Arsd t

All appear to work with the patch from users/12600, on RHEL4 linux.
So, I'll go ahead and commit.

} It would be nice to have tests but they're particularly difficult to
} write for this.

They'd probably have to use zpty and operate along the lines of the
completion tests.

Re: read -s doesn't work with -t?

[Peter Stephenson]

Bart Schaefer wrote:
> Does it even make sense to use -d and -k at the same time?

No, I can't think of a good use for this (that is, good enough to make
the code yet more complicated).  It's easy enough to loop around read -k
anyway.

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