Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: set -F kills read -t

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.

Messages sorted by: Reverse Date, Date, Thread, Author