bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions to bash "read" builtin functionality


From: Chet Ramey
Subject: Re: Questions to bash "read" builtin functionality
Date: Sat, 15 Dec 2012 17:53:09 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2

On 12/14/12 6:28 AM, Fiedler Roman wrote:
> Hello list,
> 
> One of our bash-scrips failed with very low frequency but randomly. The 
> result was that exactly 1 byte was lost, so the string returned by "read -t 
> 1" was too short. The culprit seems to be the built-in read function itself, 
> the probability of failure was about 1:100000 in our case.
> 
> After analysis and creation of a reliable reproducer, I'm not sure if this is 
> a programming error in bash or a bug in our script as the result of 
> suboptimal documentation.
> 
> * Description:
> 
> When "read" builtin is used with timeout setting, both with "-t" option or by 
> setting the "TMOUT" environment variable, and the timeout occurs when some 
> bytes of line were already received by bash, then those bytes are silently 
> dropped. The next "read" returns the remainder of the line.

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.  This also
    results in variables specified as arguments to read to be set to the empty
    string when there is no input available.  When the read builtin times out,
    it returns an exit status greater than 128.

That is not clearly stated in the manual's description of `read'.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]