Gentoo Archives: gentoo-dev

From: Andrew Savchenko <bircoph@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.
Date: Sun, 20 Dec 2015 10:18:35
Message-Id: 20151220131752.51a95ac9346a64e96aa5f0d1@gentoo.org
In Reply to: [gentoo-dev] Re: [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils. by Jonathan Callen
1 On Sat, 19 Dec 2015 18:47:45 -0500 Jonathan Callen wrote:
2 > -----BEGIN PGP SIGNED MESSAGE-----
3 > Hash: SHA512
4 >
5 > On 12/19/2015 05:56 PM, Michał Górny wrote:
6 > > On Sat, 19 Dec 2015 23:51:47 +0100 Ulrich Mueller <ulm@g.o>
7 > > wrote:
8 > >
9 > >>>>>>> On Sat, 19 Dec 2015, Michał Górny wrote:
10 > >>
11 > >>>> (I guess it is encountering EOF on the temporary file created
12 > >>>> by the string redirection, but how would one distinguish this
13 > >>>> from other errors?)
14 > >>
15 > >>> read's return code indicates whether if found a full line (with
16 > >>> a newline). read can't really fail.
17 > >>
18 > >> Certainly writing or reading the temp file can fail?
19 > >>
20 > >>>> Besides, it is hard to understand what this code does, as
21 > >>>> compared to the "set -f" solution.
22 > >>
23 > >>> Many pieces of good code are harder to understand than cheap,
24 > >>> ugly hacks. That's why those hacks are so common, and people
25 > >>> meet them all the time and never learn good code.
26 > >>
27 > >> Well, compare:
28 > >>
29 > >> set -f echo -e ${DOC_CONTENTS} | ...
30 > >>
31 > >> versus:
32 > >>
33 > >> read -d '' -r -a DOC_CONTENTS <<<"${DOC_CONTENTS}" echo -e
34 > >> "${DOC_CONTENTS[*]}" | ...
35 > >>
36 > >> The second one is (IMHO) harder to understand, less efficient,
37 > >> and relies on undocumented behaviour.
38 > >
39 > > On WHAT?!
40 > >
41 >
42 > Apparently, bash(1) and bash.info don't document what it means to pass
43 > an empty string as the argument to the -d option of the read builtin
44 > (what actually happens is that in all cases, bash uses the first
45 > character of the C string that the option gets translated to, which is
46 > '\0' for the empty string; the documentation just refers to "the first
47 > character of the string passed").
48
49 And the first and the last character of an empty string is '\0'.
50 So this behaviour is perfectly defined.
51
52
53 Best regards,
54 Andrew Savchenko