Re: read builtin does not return success code (0) in spite of it successfully read line

[Eric Blake]

On 12/27/2010 10:59 AM, Stephane CHAZELAS wrote:
> 2010-12-27, 09:43(-07), Eric Blake:
> [...]
>> On 12/26/2010 01:29 PM, Stephane CHAZELAS wrote:
>>> Bash behavior is the same as every other shell, is as documented
>>> and as specified by POSIX.
>>
>> POSIX requires that the input to read be a text file.  Since you aren't
>> passing a text file, the behavior is undefined.  POSIX does NOT require
>> bash to return failure in this case, but neither does it require bash to
>> return success.  You should not rely on the behavior of read when the
>> input does not end in a newline.
> [...]
> 
> From
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/read.html
> 
> SUSv4> EXIT STATUS
> SUSv4>
> SUSv4>      The following exit values shall be returned:
> SUSv4>
> SUSv4>       0
> SUSv4>              Successful completion.
> SUSv4>      >0
> SUSv4>              End-of-file was detected or an error occurred.
> SUSv4>

Also from the standard:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/read.html
STDIN

    The standard input shall be a text file.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html
1.4 Utility Description Defaults

When an input file is described as a "text file", the utility produces
undefined results if given input that is not from a text file, unless
otherwise stated.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html
3.395 Text File

A file that contains characters organized into zero or more lines. The
lines do not contain NUL characters and none can exceed {LINE_MAX} bytes
in length, including the <newline> character.

> 
> So I think you can expect a non-zero status here.

All you can expect is that you have undefined results.  Undefined
results include zero status.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature