[gentoo-dev] Re: Re: Default src_install for EAPI-2 or following EAPI

[Steve Long]

Vaeth wrote:

> Steve Long wrote:
>
>> Thomas Sachau wrote: [...]
>>
>> > [[ -n ${DOCS} ]] && dodoc ${DOCS}
> [...]
>>
>> It might be wise to use an array for DOCS there
>
> Since I have now seen suggestions for using arrays unnecessarily
> at least twice (see also
>   [RFC] Ability to pass arguments to src_configure/src_compile
> but I am only speaking about the usage of _arrays_ here),
> let me remark that the more clever way to this is
>
>   [ -n "${DOCS}" ] && eval "dodoc ${DOCS}"
>
eval is _not_ clever. Try: /msg greybot eval
..or check http://wooledge.org:8000/BashFAQ/048
 
> This way, people can simply quote as they like:
>
> DOCS="'filename with spaces' filename_without_space doc/*"
>
Yeuch.

> or also
>
> DOCS="just_one_filename_without_special_characters"
>
You don't need quotes there.
 
> or also - when Push from /usr/bin/functions-eix.sh is used
> (which might be implemented simpler without using other functions):
>
> Push DOCS 'filename with spaces' filename_without_space "${S}"/doc/*
>
Or just do DOCS+=(foo/* someFile 'some other File') at any point.

BASH arrays will cope with *any* character apart from NUL, which isn't
allowed in filenames. Can you _guarantee_ the same?

For instance, what if some crazy designer puts a file called:
Vaeth's "Latest" Hits
..in that doc dir; what happens after the Push function has been called and,
only at a later stage, the eval is run on the result of that glob
expansion?
 
> Not only has this the advantage that it is POSIX (and thus does not
> force ebuilds to use the particular shell "bash" - a policy which perhaps
> some day might be changed: It is dangerous to depend on a particular
> implementation),

I'm not getting back into that discussion, since we had the same one over a
period of months already. Ebuilds require BASH; get over it. If we could
move ahead with actually using BASH properly (and cleanly) it would be
nice. BASH is as portable as GNU make is, and you clearly have no issue
depending on that, and Python or C++.

BTW, POSIX sh doesn't need ${DOCS} or ${S} either, you're just wasting
characters.

> the array-less solution is also much simpler to
> implement, easy to understand from the source, and clearer in usage.

Not to me it's not, it looks awful, to read and to type, as well as being
fragile.

Furthermore you're bringing eval into the script new people are going to
look at to learn from (it's core functionality, fulfilling a basic task)
which is dangerous from a long-term pov, imo. Leave aside having to
maintain that cruft.

> Case distinctions like
>
>> if isArr DOCS; then
>>    ((${#DOCS[@]})) && dodoc "${DOCS[@]}"
>> else [[ $DOCS ]] && dodoc $DOCS
>> fi
>
> are just awful.

Actually if you factor out that isArr is a utility function (exactly like
Push) that code is very easy to follow, as well as coping with all
filenames, and itself would be part of a lib function. The only reason to
have the check is for backward-compatibility, or to allow people to use
whichever they feel most comfortable with.

One might not know how to count/use arrays in BASH, fair enough; that's how.
Given that basic knowledge[1] of the tool used to write ebuilds since the
very beginning, I cannot see how that is hard to follow.

I'm willing to bet your sh scripts aren't really as portable as you think.
If you want to see how portable sh is done, read:
http://sources.redhat.com/autobook/autobook/autobook_210.html#SEC210
(all of it) and then try to persuade us that we should be writing ebuilds
like that.

If you want to do that kind of thing, much better imo to do another type of
ebuild, eg a pbuild using Python, and only call sh when absolutely
necessary, if at all.

BTW, thanks for eix; it's a lovely utility.

[1] http://wooledge.org/mywiki/BashFAQ/005