On Sat, 19 Dec 2015 18:47:45 -0500 Jonathan Callen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 12/19/2015 05:56 PM, Michał Górny wrote:
> > On Sat, 19 Dec 2015 23:51:47 +0100 Ulrich Mueller <ulm@gentoo.org>
> > wrote:
> > 
> >>>>>>> On Sat, 19 Dec 2015, Michał Górny wrote:
> >> 
> >>>> (I guess it is encountering EOF on the temporary file created
> >>>> by the string redirection, but how would one distinguish this
> >>>> from other errors?)
> >> 
> >>> read's return code indicates whether if found a full line (with
> >>> a newline). read can't really fail.
> >> 
> >> Certainly writing or reading the temp file can fail?
> >> 
> >>>> Besides, it is hard to understand what this code does, as
> >>>> compared to the "set -f" solution.
> >> 
> >>> Many pieces of good code are harder to understand than cheap,
> >>> ugly hacks. That's why those hacks are so common, and people
> >>> meet them all the time and never learn good code.
> >> 
> >> Well, compare:
> >> 
> >> set -f echo -e ${DOC_CONTENTS} | ...
> >> 
> >> versus:
> >> 
> >> read -d '' -r -a DOC_CONTENTS <<<"${DOC_CONTENTS}" echo -e
> >> "${DOC_CONTENTS[*]}" | ...
> >> 
> >> The second one is (IMHO) harder to understand, less efficient,
> >> and relies on undocumented behaviour.
> > 
> > On WHAT?!
> > 
> 
> Apparently, bash(1) and bash.info don't document what it means to pass
> an empty string as the argument to the -d option of the read builtin
> (what actually happens is that in all cases, bash uses the first
> character of the C string that the option gets translated to, which is
> '\0' for the empty string; the documentation just refers to "the first
> character of the string passed").

And the first and the last character of an empty string is '\0'.
So this behaviour is perfectly defined.
 

Best regards,
Andrew Savchenko