1 |
On 12/28/2014 06:55 PM, Duncan wrote: |
2 |
> Zac Medico posted on Fri, 26 Dec 2014 22:52:42 -0800 as excerpted: |
3 |
> |
4 |
>>> I believe that's why I chose to stick with a make.conf file that simply |
5 |
>>> sourced a bunch of other files, instead of simply making it a directory |
6 |
>>> and sticking all those other files in the dir, when I first read about |
7 |
>>> the possibility. I have scripts myself that simply source make.conf, |
8 |
>>> that I'd have to rewrite with a for loop to process a directory. It's |
9 |
>>> not hard to do, but people haven't had to worry about it and so they |
10 |
>>> haven't. If people aren't thinking about that when they up and make |
11 |
>>> make.conf a directory, they might well wish they had! =8^0 |
12 |
>> |
13 |
>> Why don't you use 'portageq envvar'? |
14 |
> |
15 |
> Thanks for the hint. I will likely use it. =:^) |
16 |
> |
17 |
> Which hints at half the answer to your question; I didn't really know |
18 |
> about it. The other half of the answer is simple. It was never needed |
19 |
> before, as sourcing make.conf always "just worked". Now that it's |
20 |
> needed... Thanks again! =:^) |
21 |
|
22 |
Note that it's handy to pull multiple variables into your environment |
23 |
with a single portageq call like this: |
24 |
|
25 |
eval "$(portage envvar -v VARIABLE_1 VARIABLE_2 ...)" |
26 |
|
27 |
For example, we use this construct in emerge-webrsync. |
28 |
-- |
29 |
Thanks, |
30 |
Zac |