Zsh Mailing List Archive
Messages sorted by:
Re: set -F kills read -t
On 03/18/2014 10:45 AM, Bart Schaefer wrote:
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
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
(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.)
something else helpful.
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
} 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.
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.
It's just a wrapper function. In this test case, around 'grep'. I use my
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.
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
number of seconds for input, nor should it happen with functions. Or
maybe that just
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.
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: