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 <u...@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
pgpVvedGCgiN8.pgp
Description: PGP signature
