1 |
Peter Volkov wrote: |
2 |
|
3 |
> Thank you all, for your responds. |
4 |
> |
5 |
> Currently I see that the best approach is arrays. They provide required |
6 |
> functionality, clear syntax and easy upgrade path. |
7 |
++ |
8 |
|
9 |
> Speaking about the |
10 |
> latter it is: |
11 |
> |
12 |
> 1. Modify eclass to use arrays: |
13 |
> |
14 |
> for conffile in ${FONT_CONF[@]}; do |
15 |
> ... |
16 |
> done |
17 |
> |
18 |
> 2. Modify ebuilds to use arrays. |
19 |
> |
20 |
> -FONT_CONF="path1 path2" |
21 |
> +FONT_CONF=( "path1" "path2" ) |
22 |
> |
23 |
> 3. Modify eclass, so that it works with path containing spaces inside: |
24 |
> |
25 |
> -for conffile in ${FONT_CONF[@]}; do |
26 |
> +for conffile in "${FONT_CONF[@]}"; do |
27 |
> |
28 |
That looks right, although step 1 should *always* be to use the code from |
29 |
step 3. |
30 |
|
31 |
<greybot> The difference between $@ and $*: without double quotes, none at |
32 |
all: both equal $1 $2 .... With double quotes, "$@" is "$1" "$2" ..., |
33 |
while "$*" is expanded as the single argument "$1c$2c..." (where c is the |
34 |
first character of $IFS). You almost always want "$@". |
35 |
|
36 |
The same applies to the expansion of normal arrays. So for most cases, we |
37 |
use "${arr[@]}" to deal with each element separately, irrespective of its |
38 |
content. The *only* content BASH can't handle is a NUL byte, which is |
39 |
treated as end of string, eg: echo $'foo\0bar' -- pipes between commands |
40 |
are ofc binary safe; you just can't hold raw binary data in shell vars. |
41 |
|
42 |
${arr[*]} is used for display, eg die "Bad params to $FUNCNAME: $*" |
43 |
or: oIFS=$IFS; IFS=$'\n'; echo "These are the options$IFS${options[*]}" |
44 |
IFS=$oIFS # [1] |
45 |
echo ${#IFS} # to check IFS has been restored correctly |
46 |
|
47 |
[1] works fine here, Roy :) func $TAB # needs quotes though, where TAB=$'\t' |
48 |
|
49 |
|
50 |
-- |
51 |
gentoo-dev@g.o mailing list |