Re: zsh style associative array assignment bug

[Chet Ramey]

On 3/30/21 12:42 PM, Eric Cook wrote:
> On 3/30/21 10:54 AM, Chet Ramey wrote:
> > On 3/29/21 6:40 PM, Eric Cook wrote:
>
> > > Its just when populating that array dynamically with another array
> > > if that second array didn't contain `v1' hypothetically, the array gets shifted 
> > > to
> >
> > OK, how would you do that? What construct would you use in this scenario?
> Sample input:
> $ exiftool -j *.flac | jq -r '.[]| {Artist, Track, Genre, Title}|to_entries[]| .key + 
> "|" + .value'
> Artist|AK420
> Track|
> Genre|lofi
> Title|A2 - Northern Lights

That is not an array. It's output from a program. There are many ways to
parse that output, beginning with `read key value'. You attempt to create
an array from it, imperfectly, using the positional parameters, but it's
the incorrect array creation that's the problem, not the attempt to copy.

> typeset -A tags=(); set --
> while IFS='|' read -ra ary; do
>    set -- "$@" "${ary[@]}"

Is this a serious piece of code, or just one to demonstrate a programming
error?

If it's real code, I think you should reconsider your assumptions about the
behavior of `read -ra ary' given "Track|" as an input line and IFS='|'.

There is only one field, terminated by `|', which becomes one array
element. This is where you `lose' the null elements, not when you attempt
to copy. Nothing you do after it matters.

> eval 'tags=('"${*@Q}"\)

This isn't a bad approach to copying an array, but I'd use the @K modifier
instead.

Your point that the bash method of key-value pair assignment doesn't
protect you from programming errors is valid.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/