[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions to bash "read" builtin functionality (and supposed problem
Re: Questions to bash "read" builtin functionality (and supposed problem with while).
Fri, 18 Jan 2013 14:48:11 +0100
On Fri, Jan 18, 2013 at 1:48 PM, Pierre Gaston <address@hidden> wrote:
> On Fri, Jan 18, 2013 at 2:44 PM, Linus Swälas <address@hidden> wrote:
>> On Fri, Jan 18, 2013 at 12:56 PM, Pierre Gaston <address@hidden> wrote:
>>> On Fri, Jan 18, 2013 at 1:38 PM, Linus Swälas <address@hidden> wrote:
>>>> On Fri, Jan 18, 2013 at 6:57 AM, Pierre Gaston <address@hidden> wrote:
>>>>> On Thu, Jan 17, 2013 at 4:24 PM, Linus Swälas <address@hidden> 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 ....
>>> 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
>> # This first loop reads from that process substitution < <(find ... -print0)
>> while IFS= read -rd '' line
>> 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 :
>> # 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
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:
>> "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
>> 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. =)