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

[Vaeth]

Steve Long wrote:

> Vaeth wrote:
>
> > 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 is not at all related with my remark:
We were speaking about the variable DOCS, which is supposed to be
defined by a package author, not by an unreliable source.
Of course, unreliable data here may allow execution of arbitrary code,
but the package author can execute what he wants anyway.

> > This way, people can simply quote as they like:
> >
> > DOCS="'filename with spaces' filename_without_space doc/*"
> >
> Yeuch.

Well: DOCS=('filename with spaces' filename_without_space doc/*)
I cannot see much difference: ( ) vs. " " would optically IMHO not be a
reason to discuss, but the former works only in bash, the latter
practically everyhwere (and so shell programmers should be used to the
latter notation anyway).

> > or also
> >
> > DOCS="just_one_filename_without_special_characters"
> >
> You don't need quotes there.

This is true, but I wanted to show the way most people will use it.

> > 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.

So the difference is saving two tokens. Is this worth to cement
bash-dependency forever in many scripts?

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

Yes, Push does _guarantee_ the same. It is actually rather simple to
implement: It puts its argument in '...', separated by spaces,
but replaces ' in the arguments before by '\'' (the last part is a bit
tricky to do in POSIX [although not really hard - only in functions-eix.sh
this is lengthy, because a more general replacement function is used
there]. For the time being, I would not even argue against implementing
Push in a sourced script in bash: This is only one place to change if one
wants more compatibility later on).

> For instance, what if some crazy designer puts a file called:
> Vaeth's "Latest" Hits
> ..in that doc dir

no problem at all.

> Ebuilds require BASH; get over it.

My remark concerning arrays was meant to be general, not specific for
ebuilds/portage only (although I couldn't find a passage in the bible
where god claimed that ebuilds have to require bash. Actually, 99% of
the ebuilds would not need bash, if they would be modified in a completely
trivial ways (for the remaining 1% it would need a bit more work)).
If one encourages people to write ebuilds compatible, maybe even for
portage some day a change is realistic (although I am completely aware
that this is not a reasonable project for the near future).

> BASH is as portable as GNU make is, and you clearly have no issue
> depending on that, and Python or C++.

Do you know which shell might be preferrable in 5 years or 10 years?
Bets are good that thos shell will at least support POSIX;
bets are worse that this shell will support the bash-specific
treatment of arrays.

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

Yes, but that's the gentoo-recommended way to write variables -
no need to change the style just for changing it.

> > 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.

Yes, two symbols to type more is a nightmare :)
"Fragile" is not the case as I showed above.

> 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)

So why should people learn bashisms instead of compatible shell
programming? Eval is not bad in itself. It is only bad if used on
uncontrolled data which I never suggested. (Actually, a warning in an
portage manpage might be didactically more effective concerning the
dangers of the uncontrolled usage of eval than many shell introductions.)

> >> 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

Maybe my explanation was unclear here: I am not speaking about the code.
I am speaking about the way it behaves.
  DOCS='"a b"'   -> two files `"a' and `b"'
  DOCS=('"a b"') -> one file `"a b"'
this is just creating confusion by special cases.
If you say instead the argument is eval'ed, everybody who knows any shell
knows what is going on and that you have to quote correspondingly.
And the case distinction is necessary, since for arrays you cannot
shortcut (i.e. you can _never_ avoid the ( ) part) - for variables
you can (as you mentioned, in most cases you can even avoid the " " part).

> 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.

This is an old rhetorical trick (I don't know its name in English):
You impute that I claimed things which I never said - of course, then it
is easy for you to prove that these things are wrong.
I _never_ suggested to use code from stone-age for ebuilds (I did more
for the eix scripts, and I think that I succeeded meanwhile for all
architectures supported by gentoo, but I did never suggest this for
everybody. BTW: Even for these architectures only very few differences
from POSIX arose - these really old shells which do not have even
functions or other odd bugs seem to have really extinct. But this is a
different topic).

However, I strongly suggest to avoid bashisms unless absolutely
necessary and reasonable. There are scripts where this is reasonable,
but far too many scripts which use it do not belong to this category.
Using arrays to pass parameters is one of the cases of unnecessary usage
(although this is not widely known - that's that main reason why I posted
the remark).