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 ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
