Peter Volkov wrote:
> ? ???, 13/12/2007 ? 10:52 +0000, Steve Long ?????:
>> Peter Volkov wrote:
>> > Speaking about the
>> > latter it is:
>> >
>> > 1. Modify eclass to use arrays:
>> >
>> > for conffile in [EMAIL PROTECTED]; do
>> > ...
>> > done
>> >
>> > 2. Modify ebuilds to use arrays.
>> >
>> > -FONT_CONF="path1 path2"
>> > +FONT_CONF=( "path1" "path2" )
>> >
>> > 3. Modify eclass, so that it works with path containing spaces inside:
>> >
>> > -for conffile in [EMAIL PROTECTED]; do
>> > +for conffile in "[EMAIL PROTECTED]"; do
>
>> That looks right, although step 1 should *always* be to use the code from
>> step 3.
>
> No. The idea is to have after first step some kind of "backward
> compatibility". So while we have
>
> FONT_CONF="path1 path2"
>
> definitions in the tree, when I use them as array bash will expand
> [EMAIL PROTECTED] in the same way as array with exactly 1 element. And I
> do not it to be qouted as for cycle should iterate through path{1,2}. I
> know this does not work with spaces, but current implementations has the
> same limitation.
>
OIC. You could use this:
isArr() [[ $(declare -p "$1" 2>/dev/null) = 'declare -a'* ]]
with a function to carry out the actual task:
foo () { local conffile; for conffile; do .."$conffile".. ; done; }
if isArr FONT_CONF; then
foo "[EMAIL PROTECTED]"
else foo $FONT_CONF
fi || die "Unable to foo ${FONT_CONF[*]}"
- if you want to support both types of config variable. But yeah, your
migration path makes sense; sorry for missing that and thanks for your
patience.
--
[EMAIL PROTECTED] mailing list
