Re: set -F kills read -t

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Tue, 18 Mar 2014 09:22:22 -0700
Ray Andrews <rayandrews@xxxxxxxxxxx> wrote:
> I have no idea how this 'race 
> condition' stuff
> works but surely, whatever "read -t 1" has that "read -t" lacks should 
> be automatic?

No, that's the whole point of the difference!

"read -t" says "test the input state *right now*.  Trust me, I really do
mean 'right now'.  I am over 18".

"read -t 1" says "wait at most second to see if some input turns up".

When you start a pipeline,

  do-stuff-with-some-output | do-stuff-with-some-input

it's inevitable that what happens on the left and the right is going to
take some time.  The two processes are asynchronous by design.  The only
thing the shell guarantees you is that the pipeline itself will be set
up (there is some internal synchronisation to ensure there's something
running on the left and something running on the right).  When input and
output are taking place on the processes on the left and right are down
to details of those processes that the shell framework for pipelines
simply can't worry about.

So to ensure synchronisation of input and output you need to do extra
work.  The "wait a second" option is the easiest way of doing that,
although it's not a guarantee. However, there may be better ways, e.g.
you can also tell it "read 1 character, waiting until that arrives".  It
depends what you're ultimate object is.

Welcome to "non-blocking I/O"; you've now been through the first
lesson, "don't use non-blocking I/O unless you need to".

pws