Ulrich Mueller wrote:
>>>>>> On Mon, 22 Sep 2008, Kent Fredric wrote:
>
>> find /usr/share/doc/ -wholename "* *"
>> /usr/share/doc/gpac-0.4.4-r1/ISO 639-2 codes.txt.bz2
>
> Yes, and if you look into src_install of the ebuild, it does:
> dodoc doc/*.txt
>
Well at least we've established that it can and does happen.
> So a simple "dodoc ${DOCS}" with DOCS="... doc/*.txt ..." would work
> even in this case. No need for arrays.
>
That works for that specific case, yes, but it's still not a general
solution, which is what BASH arrays were invented for. For instance, an
ebuild author cannot specifically include a file with spaces, and ignore
all the other files in the same directory.
To show what I mean, given this one-liner in a terminal:
args() { (($#)) || return; echo "$# params:"; local i n=1; for i; do
echo "$n: $i"; let n++; done; }
..try these (where doc is a subdirectory of your current folder, and mem*
matches some files in it):
DOCS="doc/mem* foo"; args $DOCS
DOCS="doc/mem* 'foo bar baz'"; args $DOCS
DOCS=(doc/mem* 'foo bar baz'); args "[EMAIL PROTECTED]"
Globs work fine for a function call, or indeed for adding to an array. As
soon as you try to indirect via a variable, it has to be an array if you
want to be safe with filenames, for the general case. The same applies to
dynamic commands. See:
http://wooledge.org:8000/BashFAQ/040 and:
http://wooledge.org:8000/BashFAQ/050
Given that we're using BASH, it seems strange to preclude useful constructs.
It's a bit like telling someone to use Python without dicts (or even lists,
given how basic arrays are to virtually every programming language.) It's
much simpler to write scripts that will work with anything, and be able to
rely on them, than have to fix or work round them later.
