Using 4.0.1 on a Fedora 13 on a new build multicore AMD64, lines() for standard input returns 0 at startup when there is yet no data in the pipeline.
The command issued is:
./delcmt <fplspy.c |="" rexx="" redtab="" --="" fplspy="" home="" john="" src="" specs="" redtab:="" No="" tokentypes="" found="" in="" <stdin=""> read 0 lines.
delcmt does produce output when I type
./delcmt <fplspy.c | more
All of this worked fine on a uniprocessor Fedora6 which has now gone to the knackers' yard.
Calling linein() also returns no data, so at least it is consistent in failing. I tried adding sleep 1 to the rexx program before touching any files, but apparently the standard input stream is already open at that time, for that didn't fix it.
On unix, a read for pipes (and indeed all but regular files) may return less than the requested size even though more data are available. This used to be the original bug in OS/2, which taught me never to try to read more than 512 bytes from a stream.
A non-blocking read (which is what I think the chaps in Sindelfingen tried) won't cut it.
The bug is the atEof inline (common/platform/unix/SysFile), but I wasn't able to spot exactly why the buffer wasn't loaded.
I assume what happens now is that the pipeline and its invoking shell now run on three different cores; thus, timing is undoubtedly different. I think I've observed that the child runs before the parent on uniprocessor fork().
I've got a number of other REXX programs and they all work (but they use files rather than pipes).