Peter Volkov wrote:
> Thank you all, for your responds.
>
> Currently I see that the best approach is arrays. They provide required
> functionality, clear syntax and easy upgrade path.
++
> 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.
<greybot> The difference between $@ and $*: without double quotes, none at
all: both equal $1 $2 .... With double quotes, "$@" is "$1" "$2" ...,
while "$*" is expanded as the single argument "$1c$2c..." (where c is the
first character of $IFS). You almost always want "$@".
The same applies to the expansion of normal arrays. So for most cases, we
use "[EMAIL PROTECTED]" to deal with each element separately, irrespective of
its
content. The *only* content BASH can't handle is a NUL byte, which is
treated as end of string, eg: echo $'foo\0bar' -- pipes between commands
are ofc binary safe; you just can't hold raw binary data in shell vars.
${arr[*]} is used for display, eg die "Bad params to $FUNCNAME: $*"
or: oIFS=$IFS; IFS=$'\n'; echo "These are the options$IFS${options[*]}"
IFS=$oIFS # [1]
echo ${#IFS} # to check IFS has been restored correctly
[1] works fine here, Roy :) func $TAB # needs quotes though, where TAB=$'\t'
--
[EMAIL PROTECTED] mailing list
