[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-bash] Awkward behavior of empty arrays
From: |
DJ Mills |
Subject: |
Re: [Help-bash] Awkward behavior of empty arrays |
Date: |
Tue, 5 Sep 2017 08:41:36 -0400 |
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
>
>
>
>