| 1 |
On 03/09/2012 09:31 AM, Michael Orlitzky wrote: |
| 2 |
> On 03/09/12 12:11, Ulrich Mueller wrote: |
| 3 |
>>>>>>> On Fri, 09 Mar 2012, Michael Orlitzky wrote: |
| 4 |
>> |
| 5 |
>>>> What if bash starts to parse the script completely and barfs at |
| 6 |
>>>> 'syntax error' before it starts executing stuff? |
| 7 |
>> |
| 8 |
>>> It doesn't parse the script completely, it executes line-by-line, so |
| 9 |
>>> we can bail out early. |
| 10 |
>> |
| 11 |
>> How can you tell that this behaviour won't be changed in a future bash |
| 12 |
>> version? |
| 13 |
>> |
| 14 |
> |
| 15 |
> Who's to say that in the future my computer won't be made out of |
| 16 |
> delicious ice cream, eliminating the need for EAPIs entirely? |
| 17 |
> |
| 18 |
> Chances are, this would break thousands of scripts, so we hope they |
| 19 |
> wouldn't do it. If it does happen, we either deal with it then, or don't |
| 20 |
> upgrade to that version of bash -- the same as we would do with any |
| 21 |
> other massive breaking change. |
| 22 |
|
| 23 |
Ulrich is talking about extensions which require a newer version of |
| 24 |
bash. These kinds of extensions are quite common and don't cause |
| 25 |
"massive breaking" because people simply have to upgrade bash in order |
| 26 |
to use the new extensions, and their old scripts continue to run because |
| 27 |
the new extensions don't interfere with backward compatibility. |
| 28 |
|
| 29 |
Your eapi() function proposal is especially fragile in this context |
| 30 |
because it assumes that the installed version of bash will be able to |
| 31 |
execute a script that may target a newer version of bash. This is a |
| 32 |
special case that is typically not a problem, although it is a major |
| 33 |
problem under the specific conditions that your eapi() function approach |
| 34 |
induces. |
| 35 |
|
| 36 |
Anyway, lets focus on our main goal, which is to decide on a way to |
| 37 |
obtain the EAPI _without_ sourcing the ebuild. |
| 38 |
-- |
| 39 |
Thanks, |
| 40 |
Zac |
Archives