On Fri, Jan 18, 2013 at 1:48 PM, Pierre Gaston <pierre.gas...@gmail.com> wrote: > On Fri, Jan 18, 2013 at 2:44 PM, Linus Swälas <linus.swa...@gmail.com> wrote: >> On Fri, Jan 18, 2013 at 12:56 PM, Pierre Gaston <pierre.gas...@gmail.com> >> wrote: >>> On Fri, Jan 18, 2013 at 1:38 PM, Linus Swälas <linus.swa...@gmail.com> >>> wrote: >>>> On Fri, Jan 18, 2013 at 6:57 AM, Pierre Gaston <pierre.gas...@gmail.com> >>>> wrote: >>>>> On Thu, Jan 17, 2013 at 4:24 PM, Linus Swälas <linus.swa...@gmail.com> >>>>> wrote: >> >>>>>> I have a similar problem to report as Fiedler Roman regarding read and >> >>> From what I can see after a quick look, you are calling "read" inside >>> a "while read;do done < something" loop >>> >>> The read inside will read inside the "do done" will read from the same >>> standard input as the one after "while" and it is connected to >>> "something" and not from the terminal. >>> Maybe you want something like: >>> while IFS= read -rd '' -u3 line;do .... >>> >>> read >>> >>> done 3< <(find. .. -print0) >>> >>> using another file descriptor (3) as input to the outer loop >> >> Mmm, I don't really know where to start explaining, now since I cut away most >> of the example script, you have replied with a mixture of two >> different loops. =) >> >> I'll try to explain better in the comments to the excerpts of the script >> below: >> >> # This first loop reads from that process substitution < <(find ... -print0) >> while IFS= read -rd '' line >> do >> ... >> mkfifo "$xl_console_input" # No error checking on these, >> but currently I do get >> mkfifo "$xl_console_output" # them, I see that in the >> debugging output. >> >> # Launch "xl console" in the background, with in and output to >> the fifos. >> xl console < "$xl_console_input" > "$xl_console_output" & >> >> # Make a sub shell, can't give end of file to a fifo before >> we're actually at eof, otherwise >> # the fifo close and signals eof to the other side of the >> fifo, causing read on the receiver >> # end to terminate. Thus we need to hold the output together >> somehow, I don't know of >> # any better way than through a sub shell. >> ( >> poke_console # -> the other loop is inside here, >> described below. >> ) > "$xl_console_input" >> >> ... >> done < <(find ... -print0) >> >> >> And the other loop referenced in the poke_console line above is >> the other loop you're talking about: >> >> while : >> do >> # This read is reading from the fifo, so it's not mixed with the >> # data from the <(find ... -print0) process substitution. >> # This read apparently discards data when it times out. >> # This is the read problem. >> read -t 2 line >> ... >> done
This line does not look like this in the first example, I wrote it wrong in this attempt at clarification. :( It reads, in my first mail: done < "$xl_console_output" >> I can trick myself around it, but I believe it's a bug, especially as >> Chet Ramey wrote about this here: >> >> http://www.mail-archive.com/bug-bash@gnu.org/msg11944.html >> >> "You don't say what version of bash you're using, but the following change >> went in with bash-4.0: >> >> k. Changed the behavior of the read builtin to save any partial input >> received >> in the specified variable when the read builtin times out." >> >> Hope I managed to clarify my problem, and thanks for helping out. =) >> >> / Linus > > Check what I said, the read inside poke_console is reading from the > output of "find", > it inherits stdin from the outer loop. Absolutely, you're right, just my last example that's wrong. > (if not, please put back bug-bash in copy) So, no, it doesn't use stdin, and thus does not read from the find. =)
