Re: [Help-bash] Awkward behavior of empty arrays

[DJ Mills]

This is not a comment on what bash should or should not do, but simply a
workaround if you really need to use set -u (without which you wouldn't be
running into any issues).

You can always just put a simple conditional checking "address@hidden" for a
non-zero value before iterating.

On Tue, Sep 5, 2017 at 7:02 AM, Cristian Zoicas <address@hidden>
wrote:

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