Re: set -F kills read -t

[Ray Andrews <rayandrews@xxxxxxxxxxx>]

On 03/18/2014 10:45 AM, Bart Schaefer wrote:


Peter, Bart:

Thanks, now I at least know what was busted.  I must tread lightly on 
this point because zsh
has it's own culture, but from the perspective of my C brain, " read -t 
"  ... maybe this, maybe
that ... with exactly the same input is hard to accept.  It's not very 
robust.

> (One could argue that "read" should always erase the parameter to which
> it was told to write, no matter whether the action of reading succeeds;
> but that's a different conversation.)
I'd say it's almost the nub of this conversation.  If, as Peter says, 
zsh is asynchronous,
and that means that process one might or might not be finished before 
process two, then it
seems to me that if there is a failure of some sort, then that should be 
manifested.  Identical runs
of identical code should produce identical results, no? Or at least warn 
you if that isn't going to
happen. I appeal to the doctrine of least surprise. It should null the 
variable first, then a twit like
me would at least have some warning that something is amiss. Or it could 
print " (null) " or
something else helpful.
> } Nothing is more important than predictability.
>
> Not always true.  The point of the -t option is to tell "read" that it
> is in fact more important not to wait than it is to be predictable.
Ok, but in the context of a pipe can't we have 'wait for the input that 
IS coming. Don't wait
one second or ten seconds or no seconds, wait until the input arrives. 
Wait until the first 'echo' has done its
thing. Ain't that intuitive? When would one ever want 'read -t' to maybe 
capture input or
maybe not, depending on something unpredictable?

echo "a string" | func

should send "a string" to func absolutely every time. The very existence 
of the pipe
symbol should say 'wait for it'. Wait for 'echo' to return.
> I suspect that what you really want is the answer to the question "is
> my standard input a pipe?" and to go do something else if it is not.
> Using "read -t" gives you an unpredictable answer to that question.
>
> Without more context of what your function is meant to do when the
> input is NOT a pipe, we can't tell you the best way to answer that
> question, or even whether it's the right question in the first place.
It's just a wrapper function. In this test case, around 'grep'. I use my 
wrapper directly
but I thought it may as well be able to accept input from a pipe too. 
But this is a
matter of principal. Asynchronous piping seems almost a contradiction. 
Surely each
stage of a chain of pipes has a right to expect linear travel of data.  
This problem seems
never to happen with piped binaries, they don't seem to need to wait 
some arbitrary
number of seconds for input, nor should it happen with functions. Or 
maybe that just
can't  be done, I don't know.

Anyway, in practical terms 'read -t 1' does the trick. Most of the time. 
Not on Tuesdays
nor when I have a process running in the background that slows things 
down, but mostly
it works ;-) Not meaning to rock the boat of course, zsh does what it does.