| 1 |
>>>>> On Sat, 19 Dec 2015, Michał Górny wrote: |
| 2 |
|
| 3 |
>> (I guess it is encountering EOF on the temporary file created by |
| 4 |
>> the string redirection, but how would one distinguish this from |
| 5 |
>> other errors?) |
| 6 |
|
| 7 |
> read's return code indicates whether if found a full line (with a |
| 8 |
> newline). read can't really fail. |
| 9 |
|
| 10 |
Certainly writing or reading the temp file can fail? |
| 11 |
|
| 12 |
>> Besides, it is hard to understand what this code does, as compared |
| 13 |
>> to the "set -f" solution. |
| 14 |
|
| 15 |
> Many pieces of good code are harder to understand than cheap, ugly |
| 16 |
> hacks. That's why those hacks are so common, and people meet them |
| 17 |
> all the time and never learn good code. |
| 18 |
|
| 19 |
Well, compare: |
| 20 |
|
| 21 |
set -f |
| 22 |
echo -e ${DOC_CONTENTS} | ... |
| 23 |
|
| 24 |
versus: |
| 25 |
|
| 26 |
read -d '' -r -a DOC_CONTENTS <<<"${DOC_CONTENTS}" |
| 27 |
echo -e "${DOC_CONTENTS[*]}" | ... |
| 28 |
|
| 29 |
The second one is (IMHO) harder to understand, less efficient, and |
| 30 |
relies on undocumented behaviour. |
| 31 |
|
| 32 |
Ulrich |
Archives