On Tue, Mar 30, 2021 at 12:42:46PM -0400, Eric Cook wrote:
> typeset -A tags=(); set --
> while IFS='|' read -ra ary; do
> set -- "$@" "${ary[@]}"
> done < <(
> exiftool -j *.flac |
> jq -r '.[]| {Artist, Track, Genre, Title}|to_entries[]| .key + "|" + .value'
> )
> eval 'tags=('"${*@Q}"\)
> typeset -p tags
> declare -A tags=([lofi]="Title" [Track]="Genre" [Artist]="AK420" ["A2 -
> Northern Lights"]="" )
This is just poorly written.
declare -A tags=()
while IFS=\| read -r tag value; do
tags[$tag]=$value
done < <(exiftool ...)
In addition to the bug you demonstrated, the code as written also breaks
if there are any pipelines in the value field. (Or the tag field, but I'm
guessing that's not possible.)
One of the most *beautiful* things in bash is how "read -r var1 var2"
works. The entire remaining input line gets stored in var2, even if
it contains additional instances of the IFS delimliter. Take advantage
of this.
> Yeah, it is a programming error that could've used better validation.
> I just find it weird that the assumption of an assignment with an odd number
> of elements with
> this new syntax is that the odd number element is always a key missing a
> value that is filled in.
> when any of the keys or values could've been missing during the assignment.
I'm not disagreeing with you here, but as I pointed out earlier, there
are languages that agree with how bash currently works, languages that
agree with the "throw an error" approach, and so on.
