Hello all and sorry for the delay.
Now after reading the answers from all of you I'll resume next my
conclusions. Below you may
find comments related to your previous answer but in order to be short, I
have addressed
only problems related to my original question (empty arrays).
1) @Andy Chu
> 1. Never use anything that isn't in parentheses on the RHS of an
array initialization.
>
> OK:
> declare -a A=()
> decare -a A=(1 2 3)
While the second stamtement is ok (I mean, the array works well if I
want to find
the number of elements or to expand it), the first one is problematic.
Aparently 'declare -a A=()' works. But it works until you try to expand
"address@hidden".
Try the following code (essentially my example 2):
set -u
unset A
declare -a A=()
echo "address@hidden"
The last statement will give you the error "bash: address@hidden: unbound
variable".
So 'declare -a A=()' is not an effective way of creating empty
arrays.
I would even add that bash does not support empty arrays.
> INVALID:
> declare -a A= (your example 1)
>
>
> The way you should read this is "I'm assigning a string to an
array". Bash does the
> non-obvious thing of coercing the string to an array -- by creating
an array
> with ONE element.
In a shell context I could understand that such a statement is
invalid (if it
would be impossible or too difficult to implement it in a more user
friendly way).
Normally I would not use it, but I had the need of creating an emtpy
array, so
I wrote that statement and in the end I had the surprise of
creating an array
with a single element initialized with null.
Bash did the very-non-obvious thing of creating an array with a single
element from null.
>
> 2. Never reference an array with anything but "address@hidden" or
"${A[i]}"
where
> i is an integer (double quotes are mandatory in both cases).
>
I wouldn't but the manual says
"When there are no array members, address@hidden expands to nothing."
So "address@hidden" should be different from address@hidden Look at my
example 1.
With the statement 'declare -a A=;' I was hoping to create an empty
array. The for loop (by
luck) did what I expected: the array did not contain any elements
(I thought) so address@hidden
(not "address@hidden") expanded to nothing as the documentation says and
the statemnts inside
the loop were not executed.
On the other side if I would have written the for loop as
for e in "address@hidden"; do echo "e: ${e}"; done
the statement "echo" would have been executed.
The for loop worked because A was created as an array with a single
null element. And
the sentence "When there are no array members, address@hidden expands to
nothing." is the
manual is wrong. When an array is empty, it is considered undefined
(see my example 2).
2) @Chet Ramey
> Yes. The manual also says that assigning to an array without using a
subscript is
> equivalent to assigning to element 0 (or "0").
I think that the manual should be more clear about what is going on when
assigning null to an array when not using the syntax
name=(value1 ... valuen)
If the manual says that "declare -a A=" is equivalent with
assigning to the
element 0 then it should be included in the Arrays section.
> Example 2
> ...
>
> The real question is whether or not the size/length operator should
error out when there
> are no elements in the array. The current behavior could be
considered a bug.
>
If the current behavior could be considered a bug then it means
that bash does not support
empty arrays. Or that bash support them in a very restricted way, that
is only to create
them, but not to use them.
This is also in contradiction with the manual statement "When there are
no array members, address@hidden expands to nothing."
In my opinion bash should support
a) *real* arrays. we should have the possibility of iterating
over arrays elements even if the arrays are empty or
not. Currently that is not supported.
b) the possibility of expanding an array to the set of string
stored in its elements and if the array is empty then we must
get an empty set of strings.
regards
Cristian Zoicas