On Sat, Apr 30, 2005 at 09:52:28PM -0500, Ren? Berber wrote: >Jerry D. Hedden wrote: >[snip] >>> However, that said, the above WJFFM. In fact, it works more like linux >>> in 1.5.16 than it does on 1.5.15, i.e., the cat command exits after >>> printing "YOUR TEXT HERE" whereas it continues to block in 1.5.15. >> >> >> I tried the 4/30 snapshot of cygwin1.dll. It exhibited the behavior you >> mentioned with the 'cat' exiting after it reads text. However, this is >> a bad thing. It means that the FIFO is being set EOF after there is no >> more data. I tried my client-server app with the snapshot cygwin1.dll, >> and it failed because of this. >> >> It seems to me that the behavior of FIFOs under 1.5.15 was correct, and >> that under both 1.5.16 and the snapshot, FIFOs are now broken. > >FWIW, I just tested your example under Solaris 8 and it works just like >Christopher describes.
I think the previous <1.5.15 implementation of fifos represented my ever-evolving understanding of how they are supposed to work. Either that or it was just a bug. (FWIW, I just tried the example on another machine and still see success with 1.5.16.) If you want to more-or-less duplicate the behavior of 1.5.15 you can do something like this: (echo 99999&; echo YOUR TEXT HERE) > /tmp/FIFO As long as there is something sitting around which has the fifo open, the cat process will not terminate. Of course, there will be a long running sleep process sitting around in the above example and that may not be desirable. So, there may be a more elegant way to do this. I thought that maybe something like: cat < FIFO 42>FIFO might work since that would cause cat to keep FIFO open for input and output but that just hangs on both cygwin and linux. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
