Hi Fred,
On Thu, 7 Jan 2021, Fred Youhanaie via GLLUG wrote:
Hi Tim
Happy New Year to you too.
This is expected behaviour with pipes. The first process to open the pipe
will block until the other end opens too.
You confirm with the following - the first echo does not happen until the
shell itself has completed the open (</tmp/pipe)
time { echo hello ; read -t 1 ;} </tmp/pipe
Ah, thanks. This example helped me make sense of what was going on.
You can try something like this and drop it in the background before the read
sleep 999 >/tmp/pipe &
Neat trick. I don't actually need it now I know that the read can block
I've tweaked things so I don't get into this situation but it might be
useful in the future.
Regards,
Tim.
Cheers,
Fred
On 07/01/2021 09:31, Tim Woodall via GLLUG wrote:
Happy new year to all.
I didn't expect this:
tim@einstein(9):~$ mkfifo /tmp/pipe
tim@einstein(9):~$ time read -t 1 </tmp/pipe
real 0m13.514s
user 0m0.000s
sys 0m0.000s
tim@einstein(9):~$
in another terminal I did:
tim@einstein(10):~$ echo >/tmp/pipe
I had expected the read to time out after one second.
Is there any way to make read always timeout, even if the other end of
the pipe isn't connected?
Tim.
--
GLLUG mailing list
[email protected]
https://mailman.lug.org.uk/mailman/listinfo/gllug
