1 |
On 03/08/2012 07:03 AM, Michał Górny wrote: |
2 |
>> |
3 |
>> Someone suggested using a standard shebang the last time this came |
4 |
>> up, and if I remember correctly it was one of the least-disagreeable |
5 |
>> solutions proposed. We could of course define our own custom format, |
6 |
>> but I think something like, |
7 |
>> |
8 |
>> #!/usr/bin/eapi5 |
9 |
>> |
10 |
>> would be perfect if we could hand off the interpretation of the |
11 |
>> ebuild to that program. That solves the problem with new bash |
12 |
>> features, too, since you could point that command at a specific |
13 |
>> version. |
14 |
> |
15 |
> And what would /usr/bin/eapi5 do? Are you suggesting misusing shebang |
16 |
> or making ebuilds PM-centric? |
17 |
> |
18 |
|
19 |
I was saying that I'd prefer a more-standard use of the shebang (if |
20 |
possible), rather than defining our own header comment syntax. Either |
21 |
way I think the second option is cleaner than regular expressions. |
22 |
|
23 |
Right now, we're guaranteed the features of bash-3.2. I guess we |
24 |
actually use whatever is executing ebuild.sh to source them. But we need |
25 |
to interpret the ebuild file with something: we might as well put *that* |
26 |
in the shebang, since that's what it's for. |
27 |
|
28 |
So if we were to do this with an ebuild right now, we'd add, |
29 |
|
30 |
#!/usr/bin/eapi4 |
31 |
|
32 |
to the header, and instead of sourcing the ebuild with whatever |
33 |
ebuild.sh is using, we would run it with 'eapi4' and pass whatever we |
34 |
need back and forth. Or maybe ebuild.sh would reload itself using |
35 |
'eapi4'. If any of that makes sense, the PMS would just need to specify |
36 |
some requirements on the shebang command. |