Re: set -F kills read -t

[Bart Schaefer <schaefer@brasslantern.com>]

To add to what PWS just said ...

On Mar 18,  9:22am, Ray Andrews wrote:
}
} ... And the same run of tests is fine. I have no idea how this 'race
} condition' stuff works

"Race condition" is a term referring to what happens when two (or more)
tasks both wish to use the same resource at the same time, but the
resource is only available to one task at a time.  Think of restroom
stalls at a sports stadium at half time; someone ends up waiting, but
you can't tell in advance who will get there first.

In your case the writer is a janitor arriving to refill the paper towel
dispenser, and the reader has just used the sink and need to dry his
hands.  The -t option tells the reader that if the towel dispenser is
empty, he should immediately go away with his hands still wet.  If you
instead use -t 1, he waits 1 second to give the janitor a chance to do
his job.

}    $ echo $s | func0
}    lowercase s to a summer's day?
} 
}    $ echo $S | func0
}    lowercase s to a summer's day?   << WRONG!

The "problem" here is that $input is a global variable, so it remained
set across runs of func0.  In the second case "read -t" failed (if we
had bothered to test $? it would have been 1) so nothing new was put
into $input and the old value persisted.

You could fix this by declaring "local input;" which would cause input
to be reset every time the function is called, but that depends on
whether you want to be able to refer to $input after the function is
finished.

(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.)

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

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.

-- 
Barton E. Schaefer