[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Feature Request: scanf-like parsing
From: |
Alex fxmbsw7 Ratchev |
Subject: |
Re: Feature Request: scanf-like parsing |
Date: |
Mon, 25 Jan 2021 19:08:45 +0100 |
assoc copy without eval
root@localhost:~# unset orig copy
root@localhost:~# declare -A orig=( [a\ key]=a\ value [another\
key]=another\ value ) ; rep=$( declare -p orig )
root@localhost:~# rep=$( declare -p orig )
root@localhost:~# declare -A "copy=${rep#*=}"
root@localhost:~# declare -p copy
declare -A copy=(["another key"]="another value" ["a key"]="a value" )
root@localhost:~#
On Mon, Jan 25, 2021, 18:53 Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> On Mon, Jan 25, 2021 at 12:13:25PM -0500, Chet Ramey wrote:
> > This is good advice. If the double-quoting the @K transformation performs
> > is not what you need, use the @Q transformation to get something closer.
>
> Those don't do the same thing, though.
>
> unicorn:~$ declare -A aa=([a key]="a value" [$'\n\nx\n']=foo)
> unicorn:~$ printf %s\\n "${aa[@]@K}"
> "a key" "a value" $'\n\nx\n' "foo"
> unicorn:~$ printf %s\\n "${aa[@]@Q}"
> 'a value'
> 'foo'
>
> One gives both keys and values in a single string, while the other gives
> only values (but as multiple strings).
>
> I must say that the way @K works is surprising. I would have expected
> it to expand to a list of multiple strings (the way "$@" does, and without
> the internal quoting). I guess it's designed to support the new
> name=( key1 value1 key2 value2 ...) syntax, which I haven't used yet,
> so I don't know where all the sharp edges are.
>
> ... thinking ...
>
> It looks like @K serializes an indexed or associative array's contents
> into a string. That's a useful operation for sure. It allows you to
> do things like export an array through the environment and reconstruct
> it in a child process, albeit not seamlessly.
>
> Previously, I've seen people try to write hacks to do this by taking
> the output of "declare -p myarray" and stripping off the part up to
> and including the array's name. @K is a much cleaner way, as it gives
> just the contents, not the variable's name or flags.
>
> It's still surprising, though, which means it'll probably show up on
> my FAQ at some point, whenever people start trying to use it.
>
>
- Re: Feature Request: scanf-like parsing, (continued)
- Re: Feature Request: scanf-like parsing, Oğuz, 2021/01/25
- Re: Feature Request: scanf-like parsing, Greg Wooledge, 2021/01/25
- Re: Feature Request: scanf-like parsing, Chet Ramey, 2021/01/25
- Re: Feature Request: scanf-like parsing, Daniel Colascione, 2021/01/25
- Re: Feature Request: scanf-like parsing, Chet Ramey, 2021/01/25
- Re: Feature Request: scanf-like parsing, Greg Wooledge, 2021/01/25
- Re: Feature Request: scanf-like parsing,
Alex fxmbsw7 Ratchev <=
- Re: Feature Request: scanf-like parsing, Chet Ramey, 2021/01/25
- Re: Feature Request: scanf-like parsing, Oğuz, 2021/01/25
- Re: Feature Request: scanf-like parsing, Greg Wooledge, 2021/01/25
- Re: Feature Request: scanf-like parsing, Oğuz, 2021/01/25
- Re: Feature Request: scanf-like parsing, Alex fxmbsw7 Ratchev, 2021/01/25
- Re: Feature Request: scanf-like parsing, Léa Gris, 2021/01/25
- Re: Feature Request: scanf-like parsing, Chet Ramey, 2021/01/25
- Re: Feature Request: scanf-like parsing, Greg Wooledge, 2021/01/25
- Re: Feature Request: scanf-like parsing, Chet Ramey, 2021/01/25
- Re: Feature Request: scanf-like parsing, pepa65, 2021/01/26