Upon further testing, I've found that the issue still occurs after the
array is emptied:

========================================
$ typeset -T Foo_t=(integer x y)
$ Foo_t -a foo
$ typeset -p foo
Foo_t -a foo=()
$ foo+=(x=111 y=222)
$ foo+=(x=333 y=444)
$ echo ${!foo[@]}
0 1
$ foo=()
$ typeset -p foo
Foo_t -a foo=()
$ foo+=(x=111 y=222)
$ foo+=(x=333 y=444)
$ echo ${!foo[@]}
1 2
========================================

--
Nathan Weeks
IT Specialist
USDA-ARS Corn Insects and Crop Genetics Research Unit
http://weeks.public.iastate.edu/


On Tue, Jan 7, 2014 at 9:08 AM, Nathan Weeks <[email protected]> wrote:
> Yes, that fixed it. Thanks!
>
> --
> Nathan Weeks
> IT Specialist
> USDA-ARS Corn Insects and Crop Genetics Research Unit
> http://weeks.public.iastate.edu/
>
>
> On Mon, Jan 6, 2014 at 8:53 AM, David Korn <[email protected]> wrote:
>> No, this is a bug.  The following patch should fix it.  Let me know.
>> --- old/sh/name.c       Mon Sep 30 10:29:34 2013
>> +++ new/sh/name.c       Mon Jan  6 06:46:18 2014
>> @@ -536,7 +536,9 @@
>>                                                 {
>>
>> if((sub=nv_aimax(np)) < 0  && nv_arrayptr(np))
>>
>> errormsg(SH_DICT,ERROR_exit(1),e_badappend,nv_name(np));
>> -                                                       if(sub>=0)
>> +                                                       if(sub==0 &&
>> !np->nvalue.cp && nv_type(np))
>> +
>> nv_putsub(np,(char*)0,0,ARRAY_ADD|ARRAY_FILL);
>> +                                                       else if(sub>=0)
>>                                                                 sub++;
>>                                                 }
>>                                                 if(!nv_isnull(np) &&
>> np->nvalue.cp!=Empty && !nv_isvtree(np))
>>
>>
>>
>> On Sat, Jan 4, 2014 at 3:33 PM, Nathan Weeks <[email protected]> wrote:
>>>
>>> I have a question regarding the use of an indexed array of typed
>>> variables. When I declare such an array, and use the += operator to
>>> add a value, the first index is "1", rather than "0". Is this the
>>> intended behavior? e.g.:
>>>
>>> ========================================
>>> $ echo ${.sh.version}
>>> Version AIJM 93v- 2013-10-08
>>> $ typeset -T Foo_t=(integer x y)
>>> $ Foo_t -a foo
>>> $ foo+=(x=111 y=222)
>>> $ foo+=(x=333 y=444)
>>> $ echo ${!foo[@]}
>>> 1 2
>>> $ integer -a bar
>>> $ bar+=(111)
>>> $ bar+=(222)
>>> $ echo ${!bar[@]}
>>> 0 1
>>> ========================================
>>>
>>> The two arrays have the same number of elements, but,
>>> counterintuitively, different index values, which one has to be
>>> cognizant of when accessing the elements of these arrays.
>>>
>>> I would like to be able to set the values of such arrays in a loop; e.g.:
>>> ========================================
>>> typeset -T Foo_t=(integer x y)
>>> Foo_t -a foo
>>> integer -a bar
>>>
>>> while read -r line
>>> do
>>> ...
>>>   foo+=(x=${someval1} y=${someval2})
>>>   bar+=(${someval3})
>>> ...
>>> done
>>> ========================================
>>>
>>> However, using this method, they require different loop indexes:
>>>
>>> ========================================
>>> for (( i = 0; i < ${#bar[@]}; i++ ))
>>> do
>>> ...
>>>
>>> for (( i = 1; i < ${#foo[@]}; i++ ))
>>> do
>>> ...
>>> ========================================
>>>
>>> A less-elegant way of setting the "foo" array in a loop so that it is
>>> 0-indexed is:
>>>
>>> ========================================
>>>   foo[${#foo[@]}]=(x=${someval1} y=${someval2))
>>> ========================================
>>>
>>> However, it if the current behavior of "+=" with respect to indexed
>>> arrays of typed variables isn't well-known or relied upon, it might be a
>>> good candidate to be changed for consistency with other indexed arrays
>>> in a future release.
>>>
>>> --
>>> Nathan Weeks
>>> IT Specialist
>>> USDA-ARS Corn Insects and Crop Genetics Research Unit
>>> http://weeks.public.iastate.edu/
>>> _______________________________________________
>>> ast-users mailing list
>>> [email protected]
>>> http://lists.research.att.com/mailman/listinfo/ast-users
>>
>>
_______________________________________________
ast-users mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-users

Reply via email to