Re: Questions to bash "read" builtin functionality (and supposed problem with while).

[Linus Swälas]

On Fri, Jan 18, 2013 at 1:48 PM, Pierre Gaston <pierre.gaston@gmail.com> wrote:
> On Fri, Jan 18, 2013 at 2:44 PM, Linus Swälas <linus.swalas@gmail.com> wrote:
>> On Fri, Jan 18, 2013 at 12:56 PM, Pierre Gaston <pierre.gaston@gmail.com> 
>> wrote:
>>> On Fri, Jan 18, 2013 at 1:38 PM, Linus Swälas <linus.swalas@gmail.com> 
>>> wrote:
>>>> On Fri, Jan 18, 2013 at 6:57 AM, Pierre Gaston <pierre.gaston@gmail.com> 
>>>> wrote:
>>>>> On Thu, Jan 17, 2013 at 4:24 PM, Linus Swälas <linus.swalas@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. =)